Messages in this thread | | | Subject | Re: [PATCH 4/4] mmc: sdhci-esdhc-imx: Remove the ENGcm07207 workaround | From | Benoît Thébaudeau <> | Date | Mon, 29 May 2017 18:39:01 +0200 |
| |
On 2017/05/29 at 16:42, Ulf Hansson wrote: > On 29 May 2017 at 10:07, Adrian Hunter <adrian.hunter@intel.com> 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@wsystem.com> >> >> 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@intel.com> >> >> > > [...]
Best regards, Benoît
| |