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

[Marek Vasut <marex@denx.de>]

On Tuesday, September 01, 2015 at 05:25:00 PM, Lukasz Majewski wrote:
> Hi Marek,
> 
> > On Tuesday, September 01, 2015 at 01:19:09 PM, Lukasz Majewski wrote:
> > > Hi Marek,
> > 
> > Hi!
> > 
> > > > On Saturday, August 29, 2015 at 06:38:48 PM, Lukasz Majewski
> > > > 
> > > > wrote:
> > > > > Hi Marek,
> > > > 
> > > > Hi Lukasz,
> > > > 
> > > > > > On Saturday, August 29, 2015 at 01:55:36 PM, Lukasz Majewski
> > > > > > 
> > > > > > wrote:
> > > > > > > On Fri, 28 Aug 2015 23:55:17 +0200
> > > > > > 
> > > > > > Hi!
> > > > > > 
> > > > > > > Marek Vasut <marex@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.
> > > > > > 
> > > > > > Oops, I think I was not clear here. I was wondering what
> > > > > > happens to the card if you yank it out of the slot whole it's
> > > > > > performing it's internal cleanup or whatever. Is it possible
> > > > > > that the card suffers data corruption, effectively trashing
> > > > > > user data ?
> > > > > 
> > > > > I think that only the card manufacturer may reveal what can
> > > > > happen with the card (what policy have been implemented in
> > > > > their FW).
> > > > > 
> > > > > I guess that you may lost data in such case.
> > > > 
> > > > Uuuurgh, that's seriously shitty.
> > > > 
> > > > > > Is this behavior
> > > > > > specific to Samsung SD cards ?
> > > > > 
> > > > > I've experienced the problem with Kingston (brand new one) and
> > > > > Adata MicroSD HC (4GiB) cards.
> > > > 
> > > > I had bad previous experience with Kingston too.
> > > > 
> > > > > > > To be clear - the mentioned patch introduced regression.
> > > > > > 
> > > > > > That's a bug, not a regression, but anyway,
> > > > > > that's not the point. I do
> > > > > > agree with you that we do have a problem and I'm inclined to
> > > > > > Ack this patch, I'd like to understand what the real
> > > > > > implications of such a behavior of these cards are.
> > > > > > 
> > > > > > > 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.
> > > > > > 
> > > > > > Ew, that's one crappy card you have there. I'm reading the SD
> > > > > > card "Physical Layer Simplified Specification Version
> > > > > > 4.10" (part1_410.pdf) section 4.6.2.2 and it states that for
> > > > > > SDHC cards, the write operation should take at most 250mS,
> > > > > > for SDXC it's 500mS. Could it be that your card is violating
> > > > > > the spec ?
> > > 
> > > The "timeout" error is for situation when you issue write command
> > > (either single or multiple block) and you don't receive any response
> > > from the card.
> > > 
> > > In our case we use multiblock transfer (CMD25) with either set
> > > number of block to transfer (CMD23) or explicit end of transmission
> > > (CMD12).
> > > 
> > > Let's consider the second case.
> > > 
> > > We setup data and issue CMD25. Then we check the CMD25 status (if we
> > > don't receive reply in 250 ms we would get timeout error).
> > > Afterwards data from buffer is transmitted to the card and flashed.
> > > This operation may take long time. During this process you can issue
> > > CMD13 (SEND_STATUS) to receive information about card state ([*]
> > > 4.10. - page 85).
> > 
> > Maybe we should implement such polling through CMD13 then ? But, this
> > should be a matter for next MW, this MW we should go with increasing
> > the timeout to some 20 or 30 second. What do you think ?
> 
> For next release we can increase the timeout. Rewritting eMMC subsystem
> code is a challenging task and we will not finish until the next u-boot
> release.

Yeah, we're in agreement.