Hi Andy,
On Fri, Apr 20, 2012 at 2:09 AM, Lukasz Majewski l.majewski@samsung.com wrote:
Hi, Lei
I'm concerning with this adding init here. Since not every platform mount with emmc as boot device, and what they need is booting fast.
If I remember correctly, u-boot policy is to not initialize the mmc until it is needed (i.e. command is executed). So the extra init won't be executed until fatls or mmc is executed.
If you order them to initialize all mmc/sd at mmc register stage, this adding booting time may not be the one they want to see.
I think that booting time will not increase, because in the mmc_init() there is a check:
if (mmc->has_init) return 0;
This right here is something we need to discuss as a community. On the one hand, I can see the desire to not do unnecessary initialization every time we issue a command.
I cannot agree on that. I believe that subsystems (like MMC) shall be explicitly enabled when needed.
Moreover we cannot guarantee, that MMC subsystem will be enabled only at one place. For example mmc group of commands can explicitly enable it, but also any other command which needs access to eMMC storage will enable it.
Therefore, I think that: if (mmc->has_init) return 0;
check is needed.
Additionally we cannot check all possibilities of calling mmc_init() and due to that performing two times initialization from scratch can be catastrophic.
One more solution came to my mind. We can break u-boot policy, define a flag (e.g. CONFIG_MMC_BOOT_ON), which will always issue the mmc_init() during boot time. Then we can remove (or not execute) mmc_init() call from other commands/use cases.
On the other hand, we need some way of dealing with the possibility that the cards that were in the slot when we booted are no longer there (or that empty slots have now been filled).
One good idea would be to distinct SD cards (removable) with eMMC persistent devices.
Creating a "mmc device class" would solve the problem. Then one can assume, that eMMC is always "inserted" and no above problem appears.
With SD card one can probe (in some cards - card detect or more reliably by issuing command) when trying to send CMD to it. Response with 0xFFFF shall indicate that card has been removed.
I must check if above ideas can be implemented with new device model for u-boot.