| Message ID | 20210910092052.2457806-1-michael@walle.cc |
|---|---|
| State | Accepted |
| Commit | 285edfd7821e79de579b0bf1a7328dead2304a0b |
| Delegated to: | Peng Fan |
| Headers | show |
| Series | mmc: fsl_esdhc: remove 1ms sleep in esdhc_send_cmd_common() | expand |
Hi, On 9/10/21 6:20 PM, Michael Walle wrote: > Since the beginning of this driver which was initially for the MPC8379 > and MPC8536 SoCs, there is this spurious 1ms delay. According to the > comment it should actually be only 8 clock cycles. Esp. during EFI block > transfers, this 1ms add up to a significant delay and slows down EFI > boot. > > I couldn't find any mention in the MPC8536 that there should be a delay > of 8 clock cycles between commands. The SD card specification mentions that > the clock has to be left enabled for 8 cycles after a command or > response. But I don't see how this delay will help with this. > > Go ahead and just remove it. If there will ever be any regression we can > introduce a compile time flag, but for now I'd like to keep it simple. > > In the split off imx driver this delay was also removed in commit > 9098682200e6 ("mmc: fsl_esdhc_imx: remove the 1ms delay before sending > command"). > > Signed-off-by: Michael Walle <michael@walle.cc> If someone can test with this patch, I think that it's more better. But i don't have any objection to apply this patch. Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Best Regards, Jaehoon Chung > --- > drivers/mmc/fsl_esdhc.c | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c > index 1d98fa65c4..ebb307e950 100644 > --- a/drivers/mmc/fsl_esdhc.c > +++ b/drivers/mmc/fsl_esdhc.c > @@ -361,13 +361,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); >
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 1d98fa65c4..ebb307e950 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -361,13 +361,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);
Since the beginning of this driver which was initially for the MPC8379 and MPC8536 SoCs, there is this spurious 1ms delay. According to the comment it should actually be only 8 clock cycles. Esp. during EFI block transfers, this 1ms add up to a significant delay and slows down EFI boot. I couldn't find any mention in the MPC8536 that there should be a delay of 8 clock cycles between commands. The SD card specification mentions that the clock has to be left enabled for 8 cycles after a command or response. But I don't see how this delay will help with this. Go ahead and just remove it. If there will ever be any regression we can introduce a compile time flag, but for now I'd like to keep it simple. In the split off imx driver this delay was also removed in commit 9098682200e6 ("mmc: fsl_esdhc_imx: remove the 1ms delay before sending command"). Signed-off-by: Michael Walle <michael@walle.cc> --- drivers/mmc/fsl_esdhc.c | 7 ------- 1 file changed, 7 deletions(-)