IMX8MM SD UHS support

From: Tim Harvey <tharvey@gateworks.com>
To: u-boot@lists.denx.de
Subject: IMX8MM SD UHS support
Date: Tue, 19 Jan 2021 09:32:09 -0800	[thread overview]
Message-ID: <CAJ+vNU3dBQOrBKSqyQUxVKZVGM=0C7WU-_cCc_5qG6rSvDWbQg@mail.gmail.com> (raw)
In-Reply-To: <AM6PR06MB4691C592870E022E6672DFE9A6A40@AM6PR06MB4691.eurprd06.prod.outlook.com>

On Mon, Jan 18, 2021 at 11:38 AM ZHIZHIKIN Andrey
<andrey.zhizhikin@leica-geosystems.com> wrote:
>
> Hello Tim,
>
> Sorry it took me quite some time to get this sorted out, but I believe I was able to identify an offending commit that is preventing the USDHC to switch to higher speed modes.
>
> It is in fact b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support"), reverting it makes SD Card to properly report capabilities and switch to high speed modes.
>
> Can you try to revert this on your end to see if the SD Card would start to operate in high speed mode?
>
> I'm still investigating why this addition of wait_dat0() caused this, I believe this is due to the fact that the same wait is already performed while voltage switch to handle the errata, thus this addition wait might erroneously timeout.
>
> ++ Haibo Chen <haibo.chen@nxp.com>
>
> Haibo,
>
> Can you please explain the purpose of adding wait_dat0() Introduced with commit b5874b552f? It is not clear from the commit message what was the purpose of adding it. Have you tested the USDHC switch to higher modes with this change?

Andrey,

Reverting b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support")
does not resolve the issue. That function waits for a specified
timeout for the card to assert DAT[0] either high or low depending on
arg and is used to check for command busy or failure. The patch in
question adds that function so that the common mmc code can utilize
it. If the function does not exist in the host controller driver any
call to mmc_wait_dat0 returns -ENOSYS so it must be there to support
UHS anyway.

What is not clear to me is why the card would hold DAT[0] low on the
voltage switch indicating a failure as it does not in the Linux driver
which appears to me to be doing the same thing. Again, if we ignore
the return code UHS works fine and I'm not at all clear why you
wouldn't run into this issue:

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index a6394bc..5ea3cd2 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -579,10 +579,12 @@ static int mmc_switch_voltage(struct mmc *mmc,
int signal_voltage)
         * dat[0:3] low. Wait for at least 1 ms according to spec
         */
        err = mmc_wait_dat0(mmc, 1, 1000);
+#if 0 // hack: not clear why card always holds DAT[0] high here on
fsl_esdhc_imx
        if (err == -ENOSYS)
                udelay(1000);
        else if (err)
                return -ETIMEDOUT;
+#endif

        return 0;
 }

Honestly I don't have the time to keep delving into this. I don't have
any reason to believe that UHS has ever worked with fsl_esdhc_imx and
because my boards boot from eMMC (and HS200/HS400 works) I'm not
missing out on much by having a slow microSD.

Best regards,

Tim
