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

Alexey Brodkin Alexey.Brodkin at synopsys.com
Fri Sep 11 19:20:00 CEST 2015


Hi Marek, Lukasz,

> On Wednesday, September 09, 2015 at 09:01:30 AM, Lukasz Majewski wrote:
> > Hi,
> > 
> > > 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.
> > > 
> > > 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>
> > 
> > Are there any more questions regarding this patch or is it ready for
> > submission as fix for v2015.10?
> 
> No comments, just apply this.
> 
> But this should really be fixed properly in the next MW.
> 
> Best regards,
> Marek Vasut

FWIW I faced similar problem even reading data.
At least on one of my boards reading of ~8Mb file
took ~1.7 seconds and so 1 second timeout was interrupting data
exchange.

So indeed we need to have some dirty hack for upcoming release
like bumping timeout to something really huge but later we
need to fix that problem properly.

I though proper solution would be to set timeout depending of amount
of data to be exchanged... something like take slowest speed of SD/MMC
that is allowed by spec and calculate delay based on how much time it
might take for that slow device and for safety multiply it by say 2.

Now from this thread I see that there're other reasons that might affect
length of at least write operation. In other words it could be
complicated unfortunately.

Still we need to fix regression first with virtually infinite timeout :)
I would even thing that simple revert of Marek's patch may make sense for
now. From both points of view for keeping history clean (compared to
stacked fixes/workarounds) and from removal of regression root cause.

It's not that I like to have infinite loops but given previous
implementation worked fine for people in the previous U-Boot release.

-Alexey


More information about the U-Boot mailing list