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

[Adrian Hunter <adrian.hunter@intel.com>]

On 16/09/2026 06:49, Shawn Lin wrote:
> From: Shawn Lin <shawn.lin@linux.dev>
> 
> 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@linux.dev>
> ---
> 
>  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;

Perhaps it is safer to let drivers provide an override value,
either as an mmc_host member or create
mmc_send_tuning_timeout(host, opcode, cmd_error, timeout_ns)

>  
>  	data.sg = &sg;
>  	data.sg_len = 1;