[PATCH v2 2/2] mmc: dw_mmc-rockchip: use a tighter per-command tuning timeout

[Shawn Lin]

dw_mmc-rockchip's execute_tuning() scans the tuning window phase by phase
through mmc_send_tuning(), which applied the whole-sequence 150 ms
bound as the data timeout of every single CMD19/CMD21.  With HS200
eMMC the TMOUT register saturates at ~112 ms for the requested
150 ms, so every phase that misses the window stalls that long, and
multi-second boot slowdowns have been reported[1].

Use 5 ms per tuning command via mmc_send_tuning_timeout() instead:
~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.  A wrong
sampling phase normally fails fast with a CRC error anyway, so the
timeout only catches devices which never return the tuning block at
all.  This also bounds the cost of runtime re-tuning.

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

Changes in v2:
- Let drivers provide the timeout via a new mmc_send_tuning_timeout()
  instead of shortening the default for everybody, as suggested by
  Adrian, so it is less likely to cause a regression.
- Split into two patches; mmc_send_tuning() keeps its current
  behaviour (150 ms) and dw_mmc-rockchip opts in with 5 ms.

 drivers/mmc/host/dw_mmc-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index 75c82ff..a07707a 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -327,7 +327,7 @@ static int dw_mci_rk3288_execute_tuning(struct dw_mci *host, u32 opcode)
 						i,
 						priv->num_phases));
 
-		v = !mmc_send_tuning(mmc, opcode, NULL);
+		v = !mmc_send_tuning_timeout(mmc, opcode, NULL, 5);
 
 		if (i == 0)
 			first_v = v;
-- 
2.7.4