[U-Boot] [PATCH 2/4] mmc: dw_mmc: Zap endless timeout

[Marek Vasut <marex@denx.de>]

On Friday, September 11, 2015 at 07:04:42 PM, Alexey Brodkin wrote:
> Hi Marek,

Hi,

> On Fri, 2015-09-11 at 13:49 +-0200, Marek Vasut wrote:
> +AD4- On Friday, September 11, 2015 at 09:59:32 AM, Alexey Brodkin wrote:
> +AD4- +AD4- Hi Marek,
> +AD4-
> +AD4- Hi+ACE-
> 
> +AD4- btw Is your mailer totally broken by any chance ?
> 
> Hm, I'm not sure what happened but as I may see here
> https://patchwork.ozlabs.org/patch/516618/ my message looks good :)

That's great.

> +AD4- +AD4- It turned out that patch breaks functionality in some cases.
> +AD4- +AD4- For me on every attempt to download something significant (at
> least I see +AD4- +AD4- it on 5/7 Mb files) from SD I'm seeing timeout
> firing too early. +AD4- +AD4-
> +AD4- +AD4- I added a bit of extra instrumentation to see where time is
> spent and why. +AD4-
> +AD4- Check this patch:
> +AD4-
> +AD4- +AFs-PATCH 1/2+AF0- mmc: dw+AF8-mmc: Increase timeout to 20 seconds
> +AD4-
> +AD4- https://patchwork.ozlabs.org/patch/511899/
> +AD4-
> +AD4- Does it fix things for you ?
> 
> Well this might fix my particular test-case, but are you sure there's
> no chance for this timeout to be not long enough?

There is, the crappier the card, the higher the possibility.

> And vice versa why wait 20 seconds if problem has happened on short
> transfer? Really wait 20 seconds on boot of say TV-set just because
> USB-drive is broken?

It's still better to wait 20 seconds instead of waiting indefinitelly, right?
That is the reason for my patch, which removed the unbounded loop.

> So I would say that we need to rely on amount of data to be transferred
> instead of having any random number of seconds for all.

Let's move this discussion into the dwmmc thread by Lukasz. There is more
to it than just the amount of data transferred.

Best regards,
Marek Vasut