From: Haibo Chen <haibo.c...@nxp.com>

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.c...@nxp.com>
---
 drivers/mmc/fsl_esdhc_imx.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index a0a0903ae4..ac65ed1ee1 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -462,13 +462,6 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv 
*priv, struct mmc *mmc,
        while (esdhc_read32(&regs->prsstat) & PRSSTAT_DLA)
                ;
 
-       /* Wait at least 8 SD clock cycles before the next command */
-       /*
-        * Note: This is way more than 8 cycles, but 1ms seems to
-        * resolve timing issues with some cards
-        */
-       udelay(1000);
-
        /* Set up for a data transfer if we have one */
        if (data) {
                err = esdhc_setup_data(priv, mmc, data);
-- 
2.17.1

Reply via email to