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

[Benoît Thébaudeau]

Hi Fabio,

On Tue, Oct 24, 2017 at 10:50 AM, Fabio Estevam <festevam at gmail.com> wrote:
> 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?

Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be
the most optimal approach here, so I'll wait for the answer from your
design team before doing anything.

Best regards,
Benoît