Hi,
We use the aliases to set the MMC device order. For example: mmc0 = &emmc; mmc1 = &sdmmc; These define the MMC order in block layer. But in the mmc layer, the MMC device order is defined in the dts MMC node. It may make mistake to get MMC device order. So if we use the block layer interface to access mmc devices, use find_mmc_device to get current devnum but not uclass_get_device.
Thanks and regards, Jason
jason.zhu@rock-chips.com
From: Lokesh Vutla Date: 2019-07-25 18:39 To: Kever Yang; u-boot@lists.denx.de CC: jason.zhu@rock-chips.com; Marek Vasut; Tien Fong Chee; Peng Fan Subject: Re: [U-Boot] [PATCH] spl_mmc: always use find_mmc_device() to get mmc handler +Peng
Hi Kever,
On 25/07/19 3:10 PM, Kever Yang wrote:
Like cmd/mmc.c, the spl_mmc.c are using block driver interface like blk_dread() to access mmc devices, we need to get the mmc device handler by block driver interface so that we can always get correct device number, eg. the alias may change the device number which make the device number different in UCLASS_MMC list and UCLASS_BLK list.
Signed-off-by: Kever Yang kever.yang@rock-chips.com
common/spl/spl_mmc.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index b3619889f7..3a93e20f04 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -113,9 +113,6 @@ static int spl_mmc_get_device_index(u32 boot_device)
static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) { -#if CONFIG_IS_ENABLED(DM_MMC)
- struct udevice *dev;
-#endif int err, mmc_dev;
mmc_dev = spl_mmc_get_device_index(boot_device); @@ -130,14 +127,8 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) return err; }
-#if CONFIG_IS_ENABLED(DM_MMC)
- err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev);
- if (!err)
- *mmcp = mmc_get_mmc_dev(dev);
-#else *mmcp = find_mmc_device(mmc_dev); err = *mmcp ? 0 : -ENODEV; -#endif
I am not against the change but trying to understand what is the problem you faced. mmc_initialize() would have initialized the devices based on the seq number that is provided in DT. So in your case shouldn't uclass_get_device give the right device or something else triggered this patch?
Also we are facing a different problem with mmc_initialize(). Very early in boot there is no access to any peripheral other than boot peripheral(Need system co processor to enable peripherals). There are 2 MMC controllers in our devices. So, SD boot is failing while loading system firmware as mmc_initialize is trying to probe both the controllers. In SPL, shouldn't we just probe the needed controller instead of calling mmc_initialize?
Thanks and regards, Lokesh