Hi Fabio, On Sat, Oct 21, 2017 at 2:38 PM, Fabio Estevam <feste...@gmail.com> wrote: > On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau > <benoit.thebaudeau....@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
