[PATCH v2] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399

[PATCH v2] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399

[Yaozhong Li]

Contrary to its name, vcc_sdio is the IO supply of the SD card slot: the
schematics route it to SDMMC0_VDD. It is listed as the vmmc-supply
of the WiFi SDIO node instead, and that consumer keeps the rail from
switching to 1.8V.

The WiFi module's main VBAT input comes from vcc3v3_sys, and its IO
supply stays vcc1v8_s3.

Fix the supplies of sdio0 and sdmmc accordingly and enable SDR104, which
now becomes possible.

With UHS enabled, sequential read from a 64GB SDXC card inserted after
boot goes from 22 MB/s to 60 MB/s. WiFi remained associated at 5 GHz,
with no WiFi errors.

Assisted-by: LLM
Signed-off-by: Yaozhong Li <yaozhonguwl@gmail.com>
---
Changes in v2:
- Point the sdio0 vmmc-supply at vcc3v3_sys, the WiFi module's VBAT input,
  instead of dropping it (Heiko)
- Rewrite the commit message (Heiko)
- Link to v1: https://lore.kernel.org/all/20260922055011.14972-1-yaozhonguwl@gmail.com/

A note on testing: with a card in the slot at boot, the first
initialisation fails tuning ("All phases bad") and the card comes up in
high speed mode, as it does without this patch. A card inserted after
boot, or a rebind of the controller, comes up in SDR104; the numbers
above were taken that way.

The GRF io-domain device binds about 250 ms after fe320000.mmc here, so
SDMMC0_VDD is still configured for 3.3V when the card switches to 1.8V.
Forcing that GRF_IO_VSEL bit to 3.3V with the io-domain driver unbound
reproduces the same failure on demand. This looks like the probe
ordering issue Jonas described for the ROCK 3B [1]. It also happens with
SDR50, with a second card, and with sdio0 left without a vmmc-supply as
in v1.

If you would rather not enable UHS until that is solved, I can send the
supply changes on their own.

[1] https://lore.kernel.org/all/e9ff5387-b3c1-41a7-b251-a12789d25a70@kwiboo.se/

 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 0568dfa..fe1f8d7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -777,7 +777,7 @@ &sdio0 {
 
 	/* Power supply */
 	vqmmc-supply = <&vcc1v8_s3>;	/* IO line */
-	vmmc-supply = <&vcc_sdio>;	/* card's power */
+	vmmc-supply = <&vcc3v3_sys>;	/* card's power */
 
 	#address-cells = <1>;
 	#size-cells = <0>;
@@ -804,6 +804,8 @@ &sdmmc {
 	max-frequency = <150000000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+	sd-uhs-sdr104;
+	vqmmc-supply = <&vcc_sdio>;
 	status = "okay";
 };
 

base-commit: 940de590b839f71d6dc846160534bf202401b8b7
-- 
2.55.0.windows.3

Re: [PATCH v2] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399

[Heiko Stübner]

Am Donnerstag, 5. November 2026, 11:25:56 Mitteleuropäische Normalzeit schrieb Yaozhong Li:
> Contrary to its name, vcc_sdio is the IO supply of the SD card slot: the
> schematics route it to SDMMC0_VDD. It is listed as the vmmc-supply
> of the WiFi SDIO node instead, and that consumer keeps the rail from
> switching to 1.8V.
> 
> The WiFi module's main VBAT input comes from vcc3v3_sys, and its IO
> supply stays vcc1v8_s3.
> 
> Fix the supplies of sdio0 and sdmmc accordingly and enable SDR104, which
> now becomes possible.
> 
> With UHS enabled, sequential read from a 64GB SDXC card inserted after
> boot goes from 22 MB/s to 60 MB/s. WiFi remained associated at 5 GHz,
> with no WiFi errors.
> 
> Assisted-by: LLM
> Signed-off-by: Yaozhong Li <yaozhonguwl@gmail.com>
> ---
> Changes in v2:
> - Point the sdio0 vmmc-supply at vcc3v3_sys, the WiFi module's VBAT input,
>   instead of dropping it (Heiko)
> - Rewrite the commit message (Heiko)
> - Link to v1: https://lore.kernel.org/all/20260922055011.14972-1-yaozhonguwl@gmail.com/
> 
> A note on testing: with a card in the slot at boot, the first
> initialisation fails tuning ("All phases bad") and the card comes up in
> high speed mode, as it does without this patch. A card inserted after
> boot, or a rebind of the controller, comes up in SDR104; the numbers
> above were taken that way.
> 
> The GRF io-domain device binds about 250 ms after fe320000.mmc here, so
> SDMMC0_VDD is still configured for 3.3V when the card switches to 1.8V.
> Forcing that GRF_IO_VSEL bit to 3.3V with the io-domain driver unbound
> reproduces the same failure on demand. This looks like the probe
> ordering issue Jonas described for the ROCK 3B [1]. It also happens with
> SDR50, with a second card, and with sdio0 left without a vmmc-supply as
> in v1.
> 
> If you would rather not enable UHS until that is solved, I can send the
> supply changes on their own.
> 
> [1] https://lore.kernel.org/all/e9ff5387-b3c1-41a7-b251-a12789d25a70@kwiboo.se/
> 
>  arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> index 0568dfa..fe1f8d7 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> @@ -777,7 +777,7 @@ &sdio0 {
>  
>  	/* Power supply */
>  	vqmmc-supply = <&vcc1v8_s3>;	/* IO line */
> -	vmmc-supply = <&vcc_sdio>;	/* card's power */
> +	vmmc-supply = <&vcc3v3_sys>;	/* card's power */
>  
>  	#address-cells = <1>;
>  	#size-cells = <0>;
> @@ -804,6 +804,8 @@ &sdmmc {
>  	max-frequency = <150000000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> +	sd-uhs-sdr104;

From the schematics vcc3v3_sys also supplies the sd-slot (via an
always-on regulator / page 20 for me),  so adding

	vmmc-supply = <&vcc3v3_sys>;

would be nice, so that the declaration becomes more complete.

> +	vqmmc-supply = <&vcc_sdio>;
>  	status = "okay";
>  };


Thanks
Heiko