Hi Benoît, On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau <benoit.thebaudeau....@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
