Re: [PATCH v2 1/4] mmc: sdhci-cadence: add PHY settle after tuning for SD6HC

[NG, TZE YEE]

Hi Tanmay,

Thanks for the detailed walk-through against the spec, it matches what
I see on the hardware.


On 26/10/2026 4:17 am, Kathpalia, Tanmay wrote:
> I'll test aborting each CMD21 that fails with a command error, and
> also a single abort after tuning completes, to see whether that
> removes the CMD6 failure. If you can test the same, that would help.
> I would prefer that fix over an unconditional sleep.

I tried the abort approach and dropped the PHY settle entirely, it 
works. I now pass the command error back from mmc_send_tuning() and call 
mmc_send_abort_tuning() whenever a tap fails with a command error, i.e. 
the same thing the generic sdhci tuning path (sdhci_abort_tuning()) 
already does. Aborting only the failed tuning commands was enough; I did 
not need the extra single abort after the scan.

Tested on Agilex5 SoCDK, both media:

- eMMC (HS400): HS200 -> HS -> HS400 completes and the CMD6
  response timeout is gone. 8 GiB dd + 8 GiB fio (crc32c verify) + 2 GiB
  image write/verify all clean.

- SD (SDR104): 2 GiB image write/verify clean. Abort is a no-op here
  since CMD12 is not defined for CMD19, so the SD path is unchanged.

An ftrace of the tuning scan confirms your theory directly: a CMD21 
fails in the command phase, I issue CMD12 to abort it, and tuning then 
converges.

err_stats after boot: Command Timeout = 0, Tuning Error = 0. The one 
non-zero command CRC is the abort itself. The CMD12 is sent at that same 
failing tap, so the card's response to it is mis-sampled and counted 
(CMD12 is not a tuning opcode). The command is still delivered, the card 
leaves the Data state, so it is cosmetic. The data timeouts are tuning 
taps whose data phase did not return; data CRCs are suppressed as usual.

For v3 I'll drop the unconditional PHY settle in this patch and replace
it with the abort-on-command-error change.

Thanks,
Tze Yee