[PATCH] mmc: core: apply a per-command tuning timeout instead of the whole sequence budget

[Shawn Lin]

From: Shawn Lin <shawn.lin@xxxxxxxxx>

The tuning specs guarantee that a *sequence* of 40 tuning commands
completes within 150 ms, exclusive of any host overhead:

  eMMC, JESD84-B51B 6.6.5.1 "Sampling Tuning Sequence for HS200":

    "The Device is guaranteed to complete a sequence of 40 times CMD21
    executions within 150 ms. This is exclusive of any host overhead."

  SD Physical Layer Specification Version 4.00:

    "The card shall complete a sequence of 40 times CMD19 executions
    in no more than 150ms. The tuning process is normally shorter than
    40 executions of CMD19, and therefore should be shorter than
    150 ms."

mmc_send_tuning() however applied that 150 ms as the data timeout of
every single CMD19/CMD21, i.e. 40x the per-execution budget implied
by the specs (150 ms / 40 = 3.75 ms of device time, excluding host
overhead).

The data timeout only matters for tuning commands where the device
never returns the tuning block at all; a wrong sampling phase
normally fails fast with a CRC error instead.  Waiting 150 ms per
such test makes software phase scanning painfully slow.  With
dw_mmc-rockchip HS200 eMMC the TMOUT register saturates at ~112 ms
for the requested 150 ms, and dw_mmc's execute_tuning() scans every
phase of the tuning window, stalling that long on each phase that
misses the window.  Multi-second boot slowdowns have been reported[1].

Note that SDHCI hosts are unaffected: sdhci_send_tuning() does not
use mmc_send_tuning() (the hardware generates and checks the tuning
pattern itself) and bounds every tuning command to 50 ms in software
(sdhci.c).  The SDHCI variants which scan the tuning phases manually
through mmc_send_tuning() -- sdhci-msm, sdhci-omap, sdhci-tegra,
sdhci-cadence, sdhci-esdhc-imx, sdhci_am654, sdhci-of-k1,
sdhci-of-dwcmshc (CV180x), sdhci-of-bst and the AMD sdhci-pci
variant -- suffer from the same excessive per-command timeout and
benefit from this change as well.

Use 5 ms per tuning command.  For reference, the device serves the
tuning block straight out of its SD/MMC IP (no storage access is
involved), so even in the slowest reasonable setup -- a 64-byte
tuning block at 50 MHz over a 4-bit bus -- the block transfer alone
takes ~2.6 us, and a full tuning transaction only a few us of bus
time.  5 ms is ~1.3x the spec-implied per-execution device budget
(150 ms / 40 = 3.75 ms, excluding host overhead), 30x below the
150 ms ceiling, and the reporter verified that tuning keeps passing
with it on dw_mmc-rockchip HS200 eMMC.  Even in the worst case where
every tuning command times out, the whole tuning process stays
bounded within a few hundred milliseconds.

This also bounds the cost of runtime re-tuning, not just the tuning
performed at enumeration time.

[1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=221781
Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxx>
---

 drivers/mmc/core/mmc_ops.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index a952cc8..abcdcf8 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -708,11 +708,33 @@ int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error)
 	data.flags = MMC_DATA_READ;
 
 	/*
-	 * According to the tuning specs, Tuning process
-	 * is normally shorter 40 executions of CMD19,
-	 * and timeout value should be shorter than 150 ms
+	 * JESD84-B51B 6.6.5.1, "Sampling Tuning Sequence for HS200":
+	 *
+	 *   "The Device is guaranteed to complete a sequence of 40 times
+	 *   CMD21 executions within 150 ms. This is exclusive of any
+	 *   host overhead."
+	 *
+	 * SD Physical Layer Specification Version 4.00:
+	 *
+	 *   "The card shall complete a sequence of 40 times CMD19
+	 *   executions in no more than 150ms. The tuning process is
+	 *   normally shorter than 40 executions of CMD19, and therefore
+	 *   should be shorter than 150 ms."
+	 *
+	 * Both specs bound a *sequence* of 40 tuning commands, i.e. at
+	 * most 150/40 ms (3.75 ms) of device time per command, excluding
+	 * host overhead.  And that is generous: the device serves the
+	 * tuning block straight from its SD/MMC IP, no storage access
+	 * involved, so the whole transaction is only a few us of bus
+	 * time even in the slowest reasonable setup (64 bytes at
+	 * 50 MHz, 4-bit takes ~2.6 us).  The timeout exists solely to
+	 * catch devices which never return the block at all.
+	 *
+	 * Use 5 ms per command: ~1.3x the spec-implied per-command
+	 * budget for host overhead and slower devices, still 30x below
+	 * the 150 ms bound.
 	 */
-	data.timeout_ns = 150 * NSEC_PER_MSEC;
+	data.timeout_ns = 5 * NSEC_PER_MSEC;
 
 	data.sg = &sg;
 	data.sg_len = 1;
-- 
2.7.4