[U-Boot] [PATCH] arm: mmc: increase MMC SDHCI read status timeout

[Tom Rini]

On Tue, Jun 28, 2016 at 01:53:52PM -0700, Steve Rae wrote:
> Hi Tom,
> 
> On Tue, Jun 28, 2016 at 1:34 PM, Tom Rini <trini at konsulko.com> wrote:
> > On Tue, Jun 28, 2016 at 01:30:09PM -0700, Steve Rae wrote:
> >> Hi Stefan,
> >>
> >> On Tue, Jun 28, 2016 at 8:00 AM, Stefan Roese <sr at denx.de> wrote:
> >> > Hi Steve,
> >> >
> >> > On 27.06.2016 23:43, Steve Rae wrote:
> >> >>
> >> >> Otherwise,  ocassionally see errors like this:
> >> >>    Flashing sparse image at offset 2078720
> >> >>    Flashing Sparse Image
> >> >>    sdhci_send_command: Timeout for status update!
> >> >>    mmc fail to send stop cmd
> >> >>    write_sparse_image: Write failed, block #2181088 [0]
> >> >>
> >> >> This does not affect the actual writing speed, which is controlled by
> >> >> the default value:
> >> >>    CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT
> >> >>
> >> >> It only increases the retries when reading:
> >> >>    SDHCI_INT_STATUS
> >> >> to avoid the timeout error.
> >> >>
> >> >> Signed-off-by: Steve Rae <steve.rae at raedomain.com>
> >> >> ---
> >> >> as per the discussion in:
> >> >> http://lists.denx.de/pipermail/u-boot/2016-June/258966.html
> >> >> this supercedes:
> >> >> http://patchwork.ozlabs.org/patch/615994/
> >> >
> >> >
> >> > IIRC, I've suggested to move SDHCI_CMD_DEFAULT_TIMEOUT to Kconfig
> >> > and use the old value as default value. So that you can overwrite
> >> > it for your board / platform via your defconfig. But I have no
> >> > strong feelings here - your current version also works for
> >> > me and does not "clutter" the Kconfig subsystem with too many
> >> > values. So:
> >> >
> >> > Reviewed-by: Stefan Roese <sr at denx.de>
> >> >
> >> > Thanks,
> >> > Stefan
> >> >
> >>
> >> Thanks for the review...
> >> I didn't want to touch the "performance" algorithm related to
> >> SDHCI_CMD_DEFAULT_TIMEOUT (which maybe should be in Kconfig).
> >> However, the retry loop related to SDHCI_READ_STATUS_TIMEOUT doesn't need to
> >> be in Kconfig -- it is just a define.
> >
> > ... so how is this handled in the kernel?  I'm assuming some DT
> > property..
> >
> > --
> > Tom
> 
> ( we discussed this in the other email thread; but I'll copy it here... )

I thought I saw this in another thread, thanks.

>     It looks like (v.4.6) the code loops for max_loops=16,
>     and it looks like the loop delay is created by a write (which does not
>     exist in the U-Boot code):
>          sdhci_writel(host, mask, SDHCI_INT_STATUS);

Maybe we should rewrite the area in question, for the next release to be
like the kernel?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160628/9387bdb2/attachment.sig>