Re: [PATCH 2/2] mmc: core: sdio: skip CMD11 if signalling is already 1.8V

[Shawn Lin <shawn.lin@rock-chips.com>]

在 2026/10/24 星期六 7:28, Deomid rojer Ryabkov 写道:
> Per the SDIO Simplified Specification Version 3.00, section 3.1.2, a card
> whose signalling is already at 1.8V must report S18A = 0 in the R4
> response, and the core relies on that: it only sends CMD11
> (SD_SWITCH_VOLTAGE) when S18A is set.
> 
> Some cards don't follow this. The Realtek RTL8822CS (as fitted on the
> FriendlyElec NanoPi R2S Plus, where the M.2 SDIO bus is wired to a fixed
> 1.8V vqmmc) answers CMD5 with S18A = 1 even though the bus is already at
> 1.8V. CMD11 then times out:
> 
>    dwmmc_rockchip ff5f0000.mmc: Unexpected CMD11 timeout
>    mmc_host mmc2: Timeout sending command (cmd 0x10202000 arg 0x0 status 0x90202000)
>    mmc2: new high speed SDIO card at address 0001
> 
> and the card ends up in 50 MHz high-speed mode instead of SDR104.
> 
> When vqmmc can't do 3.3V, mmc_set_initial_signal_voltage() has already
> fallen back to 1.8V by the time CMD5 is sent, so the host knows there is
> nothing to switch. Skip CMD11 in that case. ocr keeps R4_18V_PRESENT, so
> mmc_sdio_init_uhs_card() still runs and the card is tuned to SDR104:
> 
>    dwmmc_rockchip ff5f0000.mmc: Successfully tuned phase to 64
>    mmc2: new ultra high speed SDR104 SDIO card at address 0001
> 
> Hosts that start at 3.3V are not affected, nor are compliant cards that
> report S18A = 0 at 1.8V. A non-compliant card that does need CMD11
> before entering UHS at 1.8V would now fail UHS init; with the previous
> patch it falls back to high-speed mode and keeps working.
> 
> FriendlyElec's BSP for this board works around this with a card
> quirk, MMC_QUIRK_BROKEN_ROCR_S18A[1], matched on the "realtek,rtl8822cs"
> compatible, which drops the switch request whenever this chip is


Thanks for this series.

I knew some vendor's SDIO cards misbehave it on Rockchip's bug trace
system, including this one. This patch matches what I suggested there
instead of the alternative one. FWIW,

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> present. The misreported S18A is the card's fault, but ignoring it is
> only correct when the bus is already at 1.8V: on a board with a
> switchable vqmmc the same chip would then be run in UHS at 3.3V. A card
> quirk would need knowledge of the board's supply that it doesn't have.
> The core does know the current signal voltage, so handle it there, which
> also takes care of any other card that turns out to behave the same way.
> 
> [1] https://github.com/friendlyarm/kernel-rockchip/commit/aee62cf7ae16b5ede6c6d92a8ee20e796482754e
> Cc: Jensen Huang <jensenhuang@friendlyarm.com>
> Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
> ---
>   drivers/mmc/core/sdio.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index 6787fdf1c5..a986ee04ba 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -737,9 +737,11 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
>   	 * 1.8v, the card sets S18A to 0 in the R4 response. So it will
>   	 * fails to check rocr & R4_18V_PRESENT,  but we still need to
>   	 * try to init uhs card. sdio_read_cccr will take over this task
> -	 * to make sure which speed mode should work.
> +	 * to make sure which speed mode should work. Some cards (RTL8822CS)
> +	 * set S18A regardless, so don't send CMD11 if we are already at 1.8V.
>   	 */
> -	if (rocr & ocr & R4_18V_PRESENT) {
> +	if ((rocr & ocr & R4_18V_PRESENT) &&
> +	    host->ios.signal_voltage != MMC_SIGNAL_VOLTAGE_180) {
>   		err = mmc_set_uhs_voltage(host, ocr_card);
>   		if (err == -EAGAIN) {
>   			mmc_sdio_pre_init(host, ocr_card, card);