[EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port

[Fabio Estevam <festevam@gmail.com>]

Hi Ye Li,

On Sat, Feb 27, 2021 at 3:04 AM Ye Li <ye.li@nxp.com> wrote:

> My debug shows the issue is triggered by below commit:

Thanks for investigating this issue. Appreciate it.

> commit 9098682200e6cca4b776638a51200dafa16f50fb
> Author: Haibo Chen <haibo.chen@nxp.com>
> Date:   Tue Sep 22 18:11:43 2020 +0800
>
>     mmc: fsl_esdhc_imx: remove the 1ms delay before sending command
>
>     This 1ms delay before sending command already exist from the
> beginning
>     of the fsl_esdhc driver added in year 2008. Now this driver has
> been
>     split for two files: fsl_esdhc.c and fsl_esdhc_imx.c.
> fsl_esdhc_imx.c
>     only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms
> delay
>     before sending any command. So remove this 1ms, this will save a
> lot
>     time if handling a large mmc data.
>
>     Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
>
>
> The first "go idle" command in mmc_get_op_cond seems not put SD card to
> idle status, but if adding a delay before it (like 1ms delay), then
> everything works. This commit removed 1ms delay in sending command, so
> the issue is triggered.  The root cause might be "startup-delay-us"
> needed for this regulator to reach a threshold voltage for SD working.
> Below change also can fix the issue.
>
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
>  &reg_usdhc2_vmmc {
> +       startup-delay-us = <1000>;
>         u-boot,off-on-delay-us = <20000>;
>  };
>
>
> @Haibo, Could you help looking into the issue. What's your opinion to
> add the startup-delay-us or revert your commit?

As the 1ms delay in the driver has been present since 2008, I prefer
to go with the revert for the following reasons:

1) We would need to fix all the esdhc users in devicetree.
2) By adding startup-delay-us only to the U-Boot dts we are deviating
from the Linux devicetree once again, which we should avoid.

Thanks,

Fabio Estevam