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

[Yaozhong Li]

The SD slot on this board stays at 50 MHz with 3.3V signalling. The
sdmmc node lacks both a UHS capability and its vqmmc-supply, so the
kernel never attempts the CMD11 signal voltage switch. The vendor
shipping firmware device tree declares sd-uhs-sdr104 here and points
vqmmc-supply at RK808 LDO4 (vcc_sdio), which can switch between 1.8V
and 3.0V.

Declaring those two properties alone is not enough. vcc_sdio is also
listed as the vmmc-supply of the WiFi SDIO node, and that consumer keeps
the rail from being taken down:

  vcc_sdio: Restricting voltage, 3000000-1950000uV
  mmc1: error -110 whilst initialising SD card

Using the same regulator for the WiFi card's power and for the SD card's
IO voltage is inconsistent with UHS-I operation on this board. The
vendor device tree reads it the second way: there vcc_sdio is referenced
only by the SD slot's vqmmc-supply and by the io-domains sdmmc-supply,
while the WiFi SDIO node declares no vmmc-supply at all. The WiFi module
also remained operational with the rail at 1.8V. Its own IO rail is
described separately and is left alone:

  vqmmc-supply = <&vcc1v8_s3>;	/* IO line */

That property had no effect for several years: it was added without the
brackets that make it a phandle, so it was an inert string until that
was corrected.

Drop it and declare the two properties the SD slot needs.

Tested on a Firefly-RK3399 running an Armbian 6.18.45 kernel with the
board-local device tree blob. With sd-uhs-sdr104 and the sdmmc
vqmmc-supply in place, toggling only the sdio0 vmmc-supply property, in
both directions:

  with it:    mmc1: error -110 whilst initialising SD card, then
              sd high-speed, signal voltage 3.30 V, 50 MHz
  without it: sd uhs SDR104, signal voltage 1.80 V, 148.5 MHz

Sequential read goes from 22 MB/s to 60 MB/s with a 64GB SDXC card. WiFi
remained associated at 5 GHz, -50 dBm, with no kernel errors.

Assisted-by: LLM
Signed-off-by: Yaozhong Li <yaozhonguwl at gmail.com>
---
Notes on testing, which does not belong in the permanent log:

The DTB built from the unmodified mainline DTS was not runtime-tested
with a matching mainline kernel. Built from mainline DTS and booted with
the Armbian kernel available on this board, it hangs in early boot,
before MMC initialisation, so nothing could be measured from it and no
claim is made that the patched artifact itself was boot-tested. That
baseline failure happens without this change applied and is independent
of it. The DTS was compiled and the resulting DTB inspected.

I have no schematic for this board. The claim about what LDO4 feeds
rests on the vendor firmware device tree plus the measurements above.

The analysis and the commit message were drafted with the help of an
LLM-based assistant (Claude Code), cross-reviewed with a second one
(OpenAI Codex). The device tree change, the measurements and the final
wording are mine.

 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 3 ++-
 1 file changed, 2 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..7cabbc1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -777,7 +777,6 @@ &sdio0 {
 
 	/* Power supply */
 	vqmmc-supply = <&vcc1v8_s3>;	/* IO line */
-	vmmc-supply = <&vcc_sdio>;	/* card's power */
 
 	#address-cells = <1>;
 	#size-cells = <0>;
@@ -804,6 +803,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