Message-ID:
 <TY3PR01MB1134642684DDFC5D4F1DBA76286DBA@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Mon, 1 Dec 2025 14:15:14 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Josua Mayer <josua@...id-run.com>, Ulf Hansson <ulf.hansson@...aro.org>,
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Geert Uytterhoeven
	<geert+renesas@...der.be>, magnus.damm <magnus.damm@...il.com>, wsa+renesas
	<wsa+renesas@...g-engineering.com>
CC: Mikhail Anikin <mikhail.anikin@...id-run.com>, Yazan Shhady
	<yazan.shhady@...id-run.com>, Jon Nettleton <jon@...id-run.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add mux-states
 property

Hi Josua Mayer,

Thanks for the feedback.

> -----Original Message-----
> From: Josua Mayer <josua@...id-run.com>
> Sent: 01 December 2025 14:01
> Subject: Re: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add mux-states property
> 
> Hi Biju,
> 
> Am 01.12.25 um 14:02 schrieb Biju Das:
> > Hi Josua Mayer,
> >
> >
> > Thanks for the patch.
> >
> >> -----Original Message-----
> >> From: Josua Mayer <josua@...id-run.com>
> >> Sent: 01 December 2025 12:31
> >> Subject: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add
> >> mux-states property
> >>
> >> Add mux controller support for when sdio lines are muxed between a host and multiple cards.
> >>
> >> There are several devices supporting a choice of eMMC or SD on a
> >> single board by both dip switch and gpio, e.g. Renesas RZ/G2L SMARC SoM and SolidRun RZ/G2L SoM.
> >>
> >> In-tree dts for the Renesas boards currently rely on preprocessor
> >> macros to hog gpios and define the card.
> >>
> >> By adding mux-states property to sdio controller description, boards
> >> can correctly describe the mux that already exists in hardware - and
> >> drivers can coordinate between mux selection and probing for cards.
> >> Signed-off-by: Josua Mayer <josua@...id-run.com>
> >> ---
> >>  Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> >> b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> >> index c754ea71f51f7..754ccb1c30efb 100644
> >> --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> >> +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
> >> @@ -106,6 +106,11 @@ properties:
> >>    iommus:
> >>      maxItems: 1
> >>
> >> +  mux-states:
> >> +    description:
> >> +      mux controller node to route the SDIO signals from SoC to cards.
> > Maybe describe 0 - state for SD and 1 - state for eMMC ??
> The state-mmc-sd mapping depends on the wiring and description of the mux, so we cannot differentiate
> in the mux-states property.

OK. Agreed.

> 
> The idea is that whatever numeric argument you add to the phandle will select a particular state for
> the mux.
> The rest of dt properties must still be specific to SD or eMMC, e.g.:
> 
> &sdhi0 {
>     pinctrl-0 = <&sdhi0_pins>, <&sdhi0_cd_pins>;
>     pinctrl-1 = <&sdhi0_uhs_pins>, <&sdhi0_cd_pins>;
>     pinctrl-names = "default", "state_uhs";
>     vmmc-supply = <&vmmc>;
>     vqmmc-supply = <&reg_pmic_ldo1>;
>     bus-width = <4>;
>     sd-uhs-sdr50;
>     sd-uhs-sdr104;
>     full-pwr-cycle;
>     mux-states = <&sdhi0_mux 1>;
>     status = "okay";
> };
> 
> >
> >
> >> +    maxItems: 1
> >> +
> >>    power-domains:
> >>      maxItems: 1
> >>
> >> @@ -275,6 +280,7 @@ examples:
> >>          max-frequency = <195000000>;
> >>          power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
> >>          resets = <&cpg 314>;
> >> +        mux-states = <&mux 0>;
> > On R-Car mmc/sd mux available only on SD2/SD3, so I guess you picked wrong node SD0??
> As they were examples I did not give it much thought, We could even omit mux-states from examples
> completely since it is optional.

OK, I guess that is also fine, instead of the wrong usage in sd0 device node.

> >
> > or
> >
> > Add separate example with RZ/G2L, as the boards(RZ/G2L SMARC EVK) use
> > gpio/switch (XOR function) to select the eMMC or SD signals??
> 
> I can if so desired add verbose example from our own G2L based board, e.g.:
> 
> sdhi0: mmc@...00000 {
>     compatible = "renesas,sdhi-r9a07g044", "renesas,rzg2l-sdhi";
>     reg = <0x0 0x11c00000 0 0x10000>;
>     interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
>              <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
>     clocks = <&cpg CPG_MOD R9A07G044_SDHI0_IMCLK>,
>          <&cpg CPG_MOD R9A07G044_SDHI0_CLK_HS>,
>          <&cpg CPG_MOD R9A07G044_SDHI0_IMCLK2>,
>          <&cpg CPG_MOD R9A07G044_SDHI0_ACLK>;
>     clock-names = "core", "clkh", "cd", "aclk";
>     resets = <&cpg R9A07G044_SDHI0_IXRST>;
>     power-domains = <&cpg>;
>     pinctrl-0 = <&sdhi0_pins>, <&sdhi0_cd_pins>;
>     pinctrl-1 = <&sdhi0_uhs_pins>, <&sdhi0_cd_pins>;
>     pinctrl-names = "default", "state_uhs";
>     vmmc-supply = <&vmmc>;
>     vqmmc-supply = <&reg_pmic_ldo1>;
>     bus-width = <4>;
>     sd-uhs-sdr50;
>     sd-uhs-sdr104;
>     full-pwr-cycle;
>     mux-states = <&sdhi0_mux 1>;
> };
> 
> I do not believe however that this is adding any value.

Maybe Wolfram/Geert can comment on this. Looks like SD mux is an important feature of the SoC.

Previously I got feedback to provide real example. This rule might have changed??

Cheers,
Biju

Powered by blists - more mailing lists