mmc: sdhci: remove mdelay in eMMC tuning

This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of >40ms on any emmc accesses triggering wake from runtime PM,
which can occur for a significant portion of reads on a mostly idle system.

The delay is left in place for SD Cards, which use
MMC_SEND_TUNING_BLOCK rather than MMC_SEND_TUNING_BLOCK_HS200.
I'm not able to find evidence that this is required for SD in the
specs I have access to, however this delay has been present from
initial checkin for SD so I have preserved the original behavior for
compatibility.

This has been verified to fix observed glitching on local audio
playback and recording on apps with inbuilt assumptions on storage
latency.

Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a31f06dadf6fff874a32d0ad2b20c02d8b01095b..255aaf18db3556a6f73bb2d27b9dad356b422d11 100644 (file)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1994,7 +1994,10 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
                ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                tuning_loop_counter--;
                timeout--;
-               mdelay(1);
+
+               /* eMMC spec does not require a delay between tuning cycles */
+               if (opcode == MMC_SEND_TUNING_BLOCK)
+                       mdelay(1);
        } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
 
        /*