Re: [PATCH 6/7] mmc: sdhci-of-k1: Improve RX tuning window

[Iker Pedrosa]

El lun, 7 sept 2026 a las 18:00, Hung-Chun Tseng
(<alan.tseng.cs@xxxxxxxxx>) escribió:
> So a threshold of 50 is comfortable here. It also supports your
> rationale directly: boot -2 produced a 5-code window and boot -1
> produced a 1-code window on mmc1, so the narrow-window case this
> patch guards against does occur in practice.

A jump from a minimum window size of 3 to 50 delay codes is quite dramatic.
Could you clarify how 50 was chosen? Is there a specific hardware specification,
phy datasheet recommendation, or test dataset across multiple boards that
justifies this exact number?

> My question is about the form rather than the value. The vendor
> driver takes this same limit from DT, per host:
>
>   sdh@d4280000: spacemit,rx_tuning_limit = <0x32>;  /* 50 */
>   sdh@d4280800: spacemit,rx_tuning_limit = <0x32>;  /* 50 */
>
> So 50 matches what SpacemiT already ships -- but there it is a
> per-controller DT property, and this patch turns it into a global
> compile-time constant. Was that deliberate? The vendor design implies
> the value is expected to need per-board adjustment, and with a Fixes:
> tag this will land in stable, where a board with a narrower window
> would go from "adjust the DT" to "patch and rebuild the kernel".
>
> Two options, if you think the concern is real: keep it as a DT
> property (matching the existing binding), or keep the constant as a
> default that DT can override.

I agree with Hung-Chun's point regarding configuration. Hardcoding 50 as a
global driver constant assumes all boards and trace layouts will behave
identically under thermal/power variations. Defining this limit in the Device
Tree (or allowing DT to override a sensible fallback default) would prevent
boards with slightly tighter tolerances from breaking or requiring kernel
rebuilds to boot.