summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorShawn Lin <shawn.lin@rock-chips.com>2026-09-24 16:50:23 +0800
committerUlf Hansson <ulfh@kernel.org>2026-09-29 12:45:11 +0200
commit8761866e5aaed979e071353a921220f27275d689 (patch)
treed10a96b3dc828c93a05a02fda352a29210c109a3 /tools/perf/scripts/python/task-analyzer.py
parentccf7f7a9a4fef14958fdcf19c37955144f2f25d9 (diff)
mmc: dw_mmc-rockchip: use a tighter per-command tuning timeout
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. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221781 [1] Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions