From: "Heiko Stübner" <heiko@sntech.de>
To: Yaozhong Li <yaozhonguwl@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
Shawn Lin <shawn.lin@rock-chips.com>,
Jonas Karlman <jonas@kwiboo.se>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
Yaozhong Li <yaozhonguwl@gmail.com>
Subject: Re: [PATCH v2] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399
Date: Thu, 05 Nov 2026 12:37:13 +0100 [thread overview]
Message-ID: <3342569.D8ZAKjAxdT@diego> (raw)
In-Reply-To: <20261105102556.1365-1-yaozhonguwl@gmail.com>
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
prev parent reply other threads:[~2026-11-05 11:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 10:25 [PATCH v2] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399 Yaozhong Li
2026-11-05 11:37 ` Heiko Stübner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3342569.D8ZAKjAxdT@diego \
--to=heiko@sntech.de \
--cc=devicetree@vger.kernel.org \
--cc=jonas@kwiboo.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=yaozhonguwl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox