On 2017/05/29 at 16:42, Ulf Hansson wrote: > On 29 May 2017 at 10:07, Adrian Hunter <adrian.hunter@xxxxxxxxx> 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 <benoit@xxxxxxxxxxx> >> >> 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! Please note that I had superseded this series with a v2 following Adrian's comment. >> >> Acked-by: Adrian Hunter <adrian.hunter@xxxxxxxxx> >> >> > > [...] Best regards, Benoît -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
