Re: [PATCH v5 2/3] ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support

[Frank Li <Frank.li@oss.nxp.com>]

On Wed, Aug 26, 2026 at 10:35:24AM +0200, Stefano Radaelli wrote:
> On Wed, Aug 26, 2026 at 08:31:32AM +0000, sashiko-bot@kernel.org wrote:
> > > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som-mx7customboard.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-mx7customboard.dtsi
> > > index 0000000000000..aecc8c747f041
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-mx7customboard.dtsi
> > [ ... ]
> > > +&usdhc1 {
> > > +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > > +	pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_usdhc1_gpio>;
> > > +	pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_usdhc1_gpio>;
> > > +	pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_usdhc1_gpio>;
> > > +	cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> > > +	no-1-8-v;
> >
> > [Severity: Medium]
> > Does including the no-1-8-v property here needlessly cap SD card performance
> > by explicitly disabling all 1.8V capabilities and preventing UHS-I
> > negotiation?
> >
> > The pinctrl configurations below for SD1_VSELECT prove the hardware supports
> > 1.8V switching:
> >
> > > +	pinctrl_usdhc1_gpio: usdhc1-gpiogrp {
> > > +		fsl,pins = <
> > > +			MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x59
> > > +			MX7D_PAD_GPIO1_IO08__SD1_VSELECT	0x59
> > > +		>;
> > > +	};
> >
> > With no-1-8-v present, the MMC subsystem will never switch to 1.8V, rendering
> > the UHS-I pinctrl states dead code and capping speeds at 50MHz.
>
> This is intentional. The board does not support reliable 1.8V signaling
> on this SD interface, so no-1-8-v is required despite the presence of
> the VSELECT pinmux.


Needn't pinctrl_usdhc1_100mhz and pinctrl_usdhc1_200mhz if don't support
sd3.0

Frank
>
> >
> > > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
> > > index 0000000000000..158158afc3391
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
> > [ ... ]
> > > +	codec_wm8904: sound {
> > > +		compatible = "simple-audio-card";
> > > +		simple-audio-card,bitclock-master = <&dailink_master>;
> > > +		simple-audio-card,format = "i2s";
> > > +		simple-audio-card,frame-master = <&dailink_master>;
> > > +		simple-audio-card,name = "wm8904-audio";
> > > +		simple-audio-card,routing =
> > > +			"Headphone Jack", "HPOUTL",
> > > +			"Headphone Jack", "HPOUTR",
> > > +			"IN2L", "Line In Jack",
> > > +			"IN2R", "Line In Jack",
> > > +			"IN1L", "Microphone Jack",
> > > +			"IN1R", "Microphone Jack",
> > > +			"Microphone Jack", "MICBIAS";
> >
> > [Severity: Medium]
> > Does this routing contradict the configuration of IN1L as a digital input?
> >
> > The routing maps the analog Microphone Jack to IN1L. However, the wm8904
> > node configures IN1L as a digital microphone input via wlf,in1l-as-dmicdat1:
> >
> > > +	wm8904: audio-codec@1a {
> > > +		compatible = "wlf,wm8904";
> > > +		reg = <0x1a>;
> > [ ... ]
> > > +		/* DMIC is connected to IN1L */
> > > +		wlf,in1l-as-dmicdat1;
> > > +	};
> >
> > Because IN1L is placed in digital mode, does this cause the analog signal
> > from the Microphone Jack to be ignored and break analog audio capture?
>
>
> This is intentional. IN1L is used as DMICDAT1, while the analog
> microphone path is handled through the remaining codec input routing.
> The current routing matches the board hardware configuration.
>
> Stefano