[PATCH v2] Revert "mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"

[Marek Vasut]

On 6/29/26 8:16 AM, Tanmay Kathpalia wrote:
> This reverts commit b42c67188c14 ("mmc: sdhci-cadence: trigger tuning
> for SD HS mode on SD6HC (v6) PHY").
> 
> The reverted patch introduced several issues:
> 
> 1. Non-standard tuning trigger: The SD Physical Layer Specification
>     only mandates execute_tuning for SDR50 and SDR104 UHS-I modes.
>     Triggering tuning for SD High Speed mode is outside the spec and
>     is handled via a non-standard set_ios_post callback rather than
>     through the established SDHCI framework tuning path.
> 
> 2. Non-standard device tree property: The patch introduced a new
>     "cdns,sd-hs-tuning" DT property to opt into SD HS tuning. This
>     is not aligned with existing DT bindings and bypasses the standard
>     MMC capability negotiation mechanism.
> 
> 3. Incorrect tunable mode allowlist: The sdhci_cdns6_mode_is_tuned()
>     function includes SD_HS, UHS_SDR50, and MMC_HS_400_ES as tunable
>     modes. According to the Cadence SD6HC IP User Guide (section 7.5.2,
>     Figure 18), tuning is only required for UHS-I SDR104 (SD) and
>     HS200 (eMMC). SD High Speed, UHS-I SDR50, and DDR50 only require
>     a PHY settings update from the pre-calculation script, not the
>     tuning procedure. HS400 transitions through HS200 and reuses its
>     tuned DLL value with a partial settings update. HS400ES only
>     requires a plain settings update from the calculation script with
>     no dependency on HS200 tuning.
> 
> 4. Tuned state management outside the framework: The patch manually
>     tracks tuned DLL state (tuned_mode, tuned_dll_slave_ctrl) and
>     restores it across PHY reconfigurations. This duplicates
>     responsibility that belongs in the core MMC tuning framework and
>     adds unnecessary complexity to the driver.
> 
> Reverting to realign the driver with the IP documentation and the SD
> Physical Layer Specification.
Thank you for the update.