From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fabio Estevam <festevam@gmail.com>
Date: Tue, 24 Oct 2017 06:50:31 -0200
Subject: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on
 MX25 and MX51
In-Reply-To: <CA+sos789DNUyak2UsUwTWMxreZyasimORm3OpLaOdHjU6+DLnA@mail.gmail.com>
References: <1508342223-12334-1-git-send-email-fabio.estevam@nxp.com>
 <68ea75a2-323c-ba3b-5332-eccc9885f977@wsystem.com>
 <CAOMZO5A449RS4FTfM+QM9Gq7PjhUdv4h-NdSiwA6ysAAZNtv6Q@mail.gmail.com>
 <7c61d168-eb4d-6d5c-cc19-60554424a2f1@wsystem.com>
 <CAOMZO5Ceu7sKiZvrh-r_JhgoQBNWo+cYJHq-SpG5wnSY5L3eJA@mail.gmail.com>
 <CA+sos7-UaY4gVsqu-pi+dSi3NArjYQayP3hWKAs82evPwjU5+g@mail.gmail.com>
 <CAOMZO5D4qwaXpjw5oO-7_5q_yA61+npUWDvbP_VP7Mc_BCPpQg@mail.gmail.com>
 <21485df5-402c-1ec5-bf4f-bb6c58db1464@wsystem.com>
 <CAOMZO5DpHMCdKFY8OEPos6vk4cwAnRgqoPnLTfoDkxdNofzQQA@mail.gmail.com>
 <CA+sos79AxrnYaUg574LA0sLaLORNrycfpSoVfFKYd62d-gQspg@mail.gmail.com>
 <CAOMZO5CbG60j-bhKcUzXtPWZz3w6NfEHWX74c+Tpv_-dxWj9Fg@mail.gmail.com>
 <CA+sos789DNUyak2UsUwTWMxreZyasimORm3OpLaOdHjU6+DLnA@mail.gmail.com>
Message-ID: <CAOMZO5Br4tQ80BK4vPAGZtFKwczJj+ue7Wa4sSyFAby8QPQG2A@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: u-boot@lists.denx.de

Hi Benoît,

On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau
<benoit.thebaudeau.dev@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