[U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds

[Lukasz Majewski]

On Fri, 28 Aug 2015 23:55:17 +0200
Marek Vasut <marex at denx.de> wrote:

> On Friday, August 28, 2015 at 03:50:20 PM, Lukasz Majewski wrote:
> > The commit: d9dbb97be0e4a550457aec5f11afefb446169c90
> > "mmc: dw_mmc: Zap endless timeout" removed endless loop waiting for
> > end of dw mmc transfer.
> > 
> > For some workloads - dfu test @ Odroid XU3 (sending 8MiB file) -
> > and SD cards (e.g. MicroSD Kingston 4GiB, Adata 4GiB)
> > the default timeout is to short.
> > 
> > The new value - 20 seconds - takes into account the situation when
> > SD card triggers internal clean up. Such process may take more than
> > 10 seconds on some cards.
> 
> What happens if you pull the SD card out of the slot during such a
> process?

Then we would wait 20 seconds :-) to proceed.

To be clear - the mentioned patch introduced regression. It works for
small files on a commonly available SD cards (like 4 GiB
Kingston/Adata).

When I ran DFU tests I've discovered that there is a problem with
storing 8MiB file (dat_8M.img). 

Even worse - when one wants to store Image.itb file (which might be 4-6
MiB) it sometimes works and sometimes not. Nightmare for debugging.

Please correct me if I'm wrong - but is seems like we are now using 1
second timeout for detection if SD card has been removed?

Shouldn't we use polling on the card detect IO pin instead? We could add
such polling in several places in the MMC subsystem (like we do it
with watchdog).

Marek, Pantelis, what do you think about this?

> 
> Also, where did you find out there is such "cleanup" mechanism
> please ?

Internally we did some tests with several SD cards. We were stunned when
it turned out that for some workloads it took up to 15 seconds to
end write operation for small data.

The culprit is the SD Card embedded controller responsible for FTL -
flash translation layer.
It allows NAND memory on the card to be visible as the block device.
More importantly it also takes care of wear leveling and bad block
management.

Hence, we don't know when it would start housekeeping operations.
We can only poll/wait until this controller finishes it work.
The code as it was (with the indefinite loop) was taking this situation
into account. 

The 1 second timeout is apparently too short and makes using SD card
non-deterministic and error prone in u-boot.

Even worse, many devices use SD card as the only storage device.

> 
> > Signed-off-by: Lukasz Majewski <l.majewski at samsung.com>
> > Cc: Marek Vasut <marex at denx.de>
> > Cc: Pantelis Antoniou <panto at antoniou-consulting.com>
> > Cc: Tom Rini <trini at konsulko.com>
> > ---
> >  drivers/mmc/dw_mmc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> > index 77b87e0..21a92d2 100644
> > --- a/drivers/mmc/dw_mmc.c
> > +++ b/drivers/mmc/dw_mmc.c
> > @@ -213,7 +213,7 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > 
> >  	if (data) {
> >  		start = get_timer(0);
> > -		timeout = 1000;
> > +		timeout = 20000;
> >  		for (;;) {
> >  			mask = dwmci_readl(host, DWMCI_RINTSTS);
> >  			/* Error during data transfer. */
> 
> Best regards,
> Marek Vasut

Best regards,

Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150829/fb200c0f/attachment.sig>