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>
This commit is contained in:
parent
252f29a916
commit
197160d52e
|
@ -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);
|
||||
|
||||
/*
|
||||
|
|
Loading…
Reference in New Issue