From: Haibo Chen haibo.chen@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.chen@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(®s->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);