On 29 May 2017 at 10:07, Adrian Hunter <[email protected]> wrote: > On 03/05/17 13:05, Benoît Thébaudeau wrote: >> The SDHCI_QUIRK_NO_MULTIBLOCK quirk was used as a workaround for the >> ENGcm07207 erratum. However, it caused excruciatingly slow SD transfers >> (300 kB/s on average), and this erratum actually does not imply that >> multiple-block transfers are not supported, so this was overkill. >> >> The suggested workaround for this erratum is to set SYSCTL.RSTA, but the >> simple DAT line software reset (which resets the DMA circuit among >> others) triggered by sdhci_finish_data() in case of errors seems to be >> sufficient. Indeed, generating errors in a controlled manner on i.MX25 >> using the FEVT register right in the middle of read data transfers >> without this quirk shows that nothing is written to the buffer by the >> eSDHC past CMD12, and no extra Auto CMD12 is sent with AC12EN set, so >> the data transfers on AHB are properly aborted. For write data >> transfers, neither extra data nor extra Auto CMD12 is sent, as expected. >> Moreover, after intensive stress tests on i.MX25, removing >> SDHCI_QUIRK_NO_MULTIBLOCK seems to be safe. >> >> Signed-off-by: Benoît Thébaudeau <[email protected]> > > Aside from one comment below... > > I would expect to see Acks from other sdhci-esdhc-imx users. Nevertheless, > for sdhci:
Yes, I would also appreciate some ack/tested by, from the corresponding sdhci variant users of this series. However, to allow it to get some results from linux-next, I have queued up this series for next (amending $subject patch according to the comment from Adrian). Thanks! > > Acked-by: Adrian Hunter <[email protected]> > > [...] Kind regards Uffe
