[U-Boot] [RESEND 2/2] mmc:fix Call mmc_init() when executing mmc_get_dev()

[Lukasz Majewski <l.majewski@samsung.com>]

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.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group