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

[Fabio Estevam]

Hi Benoît,

On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev at gmail.com> wrote:

> 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?

I can try to ask it internally when I am back to the office next week.

> 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.

Can we also do like this in U-Boot for now?

Thanks