Hi Fabio, On Tue, Oct 24, 2017 at 10:50 AM, Fabio Estevam <feste...@gmail.com> wrote: > 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?
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
