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 <tr...@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 <s...@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....@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 <s...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
