All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399
Date: Fri, 06 Nov 2026 09:09:30 +0100	[thread overview]
Message-ID: <6900453.LvFx2qVVIh@diego> (raw)
In-Reply-To: <20261106061835.1316-1-yaozhonguwl@gmail.com>

Hi,

Am Freitag, 6. November 2026, 07:18:35 Mitteleuropäische Normalzeit schrieb Yaozhong Li:
[...]
> - Describe the slot's own supply, vcc_sd, and use it as the sdmmc
>   vmmc-supply (Heiko). It is fed from vcc3v3_sys, and GPIO4_D6 controls
>   the slot power switch: holding the pin low leaves the card unpowered.
>   This is the same arrangement as vcc3v0_sd on the ROC-PC. The existing,
>   unreferenced lcd_panel_reset pinctrl entry also names GPIO4_D6; the
>   vendor tree uses the pin only for vcc_sd.

I you're reading the schematics, this is wrong.

In the schematics file Shawn linked to earlier (and also the one I have),
GPIO4_D6 is connected to the reset-pin of an AT18.

While the vcc3v0_sd is an always on regulator coming from vcc3v3_sys.
As stated in v2, see page 20 of your schematics.

So you essentially just set vmmc-supply to vcc3v3_sys. As I said that is
merely descriptive.


Heiko

> - Link to v2: https://lore.kernel.org/all/20261105102556.1365-1-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/
> 
> On the boot-time issue described in v2: with the vmmc-supply in place
> the sdmmc controller now probes after the GRF io-domain here, and a card
> present at boot came up in SDR104 in 5 of 5 warm boots, against 0 of 8
> before. That is a change in probe order rather than a fix for the
> ordering problem itself.
> 
>  .../boot/dts/rockchip/rk3399-firefly.dts      | 24 ++++++++++++++++++-
>  1 file changed, 23 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..03858a4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> @@ -233,6 +233,19 @@ vcc5v0_typec: regulator-vcc5v0-typec {
>  		vin-supply = <&vcc_sys>;
>  	};
>  
> +	vcc_sd: regulator-vcc-sd {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc_sd_en>;
> +		regulator-name = "vcc_sd";
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
>  	vcc_sys: regulator-vcc-sys {
>  		compatible = "regulator-fixed";
>  		regulator-name = "vcc_sys";
> @@ -731,6 +744,12 @@ wifi_enable_h: wifi-enable-h {
>  		};
>  	};
>  
> +	sdmmc {
> +		vcc_sd_en: vcc-sd-en {
> +			rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
>  	usb-typec {
>  		vcc5v0_typec_en: vcc5v0_typec_en {
>  			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
> @@ -777,7 +796,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 +823,9 @@ &sdmmc {
>  	max-frequency = <150000000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_sd>;
> +	vqmmc-supply = <&vcc_sdio>;
>  	status = "okay";
>  };
>  
> 
> base-commit: 940de590b839f71d6dc846160534bf202401b8b7
> 





WARNING: multiple messages have this Message-ID (diff)
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 v3] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399
Date: Fri, 06 Nov 2026 09:09:30 +0100	[thread overview]
Message-ID: <6900453.LvFx2qVVIh@diego> (raw)
In-Reply-To: <20261106061835.1316-1-yaozhonguwl@gmail.com>

Hi,

Am Freitag, 6. November 2026, 07:18:35 Mitteleuropäische Normalzeit schrieb Yaozhong Li:
[...]
> - Describe the slot's own supply, vcc_sd, and use it as the sdmmc
>   vmmc-supply (Heiko). It is fed from vcc3v3_sys, and GPIO4_D6 controls
>   the slot power switch: holding the pin low leaves the card unpowered.
>   This is the same arrangement as vcc3v0_sd on the ROC-PC. The existing,
>   unreferenced lcd_panel_reset pinctrl entry also names GPIO4_D6; the
>   vendor tree uses the pin only for vcc_sd.

I you're reading the schematics, this is wrong.

In the schematics file Shawn linked to earlier (and also the one I have),
GPIO4_D6 is connected to the reset-pin of an AT18.

While the vcc3v0_sd is an always on regulator coming from vcc3v3_sys.
As stated in v2, see page 20 of your schematics.

So you essentially just set vmmc-supply to vcc3v3_sys. As I said that is
merely descriptive.


Heiko

> - Link to v2: https://lore.kernel.org/all/20261105102556.1365-1-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/
> 
> On the boot-time issue described in v2: with the vmmc-supply in place
> the sdmmc controller now probes after the GRF io-domain here, and a card
> present at boot came up in SDR104 in 5 of 5 warm boots, against 0 of 8
> before. That is a change in probe order rather than a fix for the
> ordering problem itself.
> 
>  .../boot/dts/rockchip/rk3399-firefly.dts      | 24 ++++++++++++++++++-
>  1 file changed, 23 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..03858a4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
> @@ -233,6 +233,19 @@ vcc5v0_typec: regulator-vcc5v0-typec {
>  		vin-supply = <&vcc_sys>;
>  	};
>  
> +	vcc_sd: regulator-vcc-sd {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc_sd_en>;
> +		regulator-name = "vcc_sd";
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
>  	vcc_sys: regulator-vcc-sys {
>  		compatible = "regulator-fixed";
>  		regulator-name = "vcc_sys";
> @@ -731,6 +744,12 @@ wifi_enable_h: wifi-enable-h {
>  		};
>  	};
>  
> +	sdmmc {
> +		vcc_sd_en: vcc-sd-en {
> +			rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
>  	usb-typec {
>  		vcc5v0_typec_en: vcc5v0_typec_en {
>  			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
> @@ -777,7 +796,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 +823,9 @@ &sdmmc {
>  	max-frequency = <150000000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_sd>;
> +	vqmmc-supply = <&vcc_sdio>;
>  	status = "okay";
>  };
>  
> 
> base-commit: 940de590b839f71d6dc846160534bf202401b8b7
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2026-11-06  8:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  6:18 [PATCH v3] arm64: dts: rockchip: enable SD UHS-I on Firefly-RK3399 Yaozhong Li
2026-11-06  6:18 ` Yaozhong Li
2026-11-06  6:29 ` sashiko-bot
2026-11-06  8:09 ` Heiko Stübner [this message]
2026-11-06  8:09   ` Heiko Stübner

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=6900453.LvFx2qVVIh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.