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 thebeginning 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)
®_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