[U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

[Benoît Thébaudeau]

Hi Fabio,

On Sat, Oct 21, 2017 at 2:38 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau
> <benoit.thebaudeau.dev at gmail.com> wrote:
>
>> I already have a mainline version working at HS with changes only in
>> fsl_esdhc.c (apart from the port of my board). I still have to narrow
>> these changes down to the issue.
>
> Ok, great!

The issue is the timeout in esdhc_setup_data() on line 309. If I
revert e978a31b and fb823981, then everything works fine. However, the
latest calculation is correct, so reverting these commits is not the
fix. Indeed, for HS transfers:
mmc->tran_speed = 50000000, fls(mmc->tran_speed/4) = 24
mmc->clock = 48000000, fls(mmc->clock/2) = 25
I've tested with 26 and 27, and they work fine. Therefore,
SYSCTL.DTOCV is broken for 25 - 13 = 12 here, so the i.MX25 has an
undocumented erratum, which could just happen to be
CONFIG_SYS_FSL_ERRATUM_ESDHC_A001. If it's not exactly this erratum,
then a new workaround could be implemented for it, or
ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE could be used instead. Can you ask
your design team to confirm this?

Shouldn't CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 be changed into a quirk to
be defined in a SoC header file (such as
arch/arm/include/asm/arch-mx25/imx-regs.h) or in
drivers/mmc/fsl_esdhc.c if an affected SoC or IP version is detected
from the configuration, rather than keeping it as a configuration
setting to be defined in a board configuration file (such as
include/configs/mx25pdk.h)?

Note that it would be possible to go further than fb823981 to optimize
this timeout because mmc->clock is also not always the actual SD clock
frequency resulting from set_sysctl(). However, timeout cases should
normally never occur, so optimizing them is a bit pointless.

Note that mainline Linux always uses the maximum timeout regardless of
the SD clock frequency.

I've also noticed that the PIO mode fails (even with the commits above
reverted) for write accesses (read accesses work fine) with "Data
Write Failed in PIO Mode.". I have not investigated this issue yet.
This is also related to a timeout, but the root cause could be
somewhere else, e.g. in the changes introduced in esdhc_setup_data()
for the PIO mode.

Best regards,
Benoît