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

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

On Tue, Aug 25, 2026 at 07:16:48AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] The `sw1a` regulator maximum voltage is set to 3.3V, which violates the i.MX7D core voltage limits (typically 1.0V, max 1.15V) and the PFUZE3000 SW1A hardware limit for this design (max 1.475V).
> - [High] Deleting `fsl,sai-mclk-direction-output` prevents the SoC from outputting the required Master Clock (MCLK) to the WM8731 audio codec.
> - [Medium] The `sd3-pwr-hog` GPIO hog on `gpio6 11` directly conflicts with the native `usdhc3` pinctrl configuration for `SD3_RESET_B`.
> --
>
> --- Patch [2]: [PATCH v4 2/3] ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support ---
> commit a699faaceb07c2b3521d089b94e7deba5e25dd8b
> Author: Stefano Radaelli <stefano.r@variscite.com>
>
> ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support
>
> Add device tree support for the Variscite VAR-SOM-MX7 system on module.
> The module is based on the NXP i.MX7Dual SoC.
>
> Link: https://variscite.com/system-on-module-som/i-mx-7/var-som-mx7/
>
> > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi
> [ ... ]
> > +&gpio6 {
> > +	sd3-pwr-hog {
> > +		gpio-hog;
> > +		gpios = <11 0>;
> > +		output-low;
> > +		line-name = "sd3_pwr";
> > +	};
> > +};
> [ ... ]
> > +&iomuxc {
> > +	pinctrl_usdhc3: usdhc3grp {
> > +		fsl,pins = <
> > +			MX7D_PAD_SD3_RESET_B__SD3_RESET_B	0x59
>
> [Severity: Medium]
> Does this GPIO hog conflict with the native usdhc3 pinctrl configuration
> for SD3_RESET_B?
>
> The sd3-pwr-hog statically claims gpio6 11, which corresponds to
> MX7D_PAD_SD3_RESET_B. The pinctrl_usdhc3 later claims the exact same pad as
> SD3_RESET_B in its native mode.
>

Is it true?

> Could this cause a device tree resource conflict over the pad, and
> potentially spuriously reset the eMMC during sleep transitions if the
> pin reverts to the driven-low GPIO state?
>
> > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi
> [ ... ]
> > +&sai1 {
> > +	assigned-clock-rates = <0>, <36864000>;
> > +	/delete-property/ fsl,sai-mclk-direction-output;
> > +};
>
> [Severity: High]
> Does deleting the fsl,sai-mclk-direction-output property prevent the SoC
> from outputting the required master clock to the WM8731 audio codec?
>
> The WM8731 codec requires an MCLK to function. By removing this direction
> property, the SAI block might configure the pad as an input, which would leave
> the codec without a master clock from the SoC.
>
> > diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
> [ ... ]
> > +&i2c1 {
> [ ... ]
> > +	pfuze300: pmic@8 {
> > +		compatible = "fsl,pfuze3000";
> > +		reg = <0x08>;
> > +
> > +		regulators {
> > +			sw1a_reg: sw1a {
> > +				regulator-min-microvolt = <700000>;
> > +				regulator-max-microvolt = <3300000>;
>
> [Severity: High]
> Does setting the sw1a maximum voltage to 3.3V violate the hardware limits
> for the i.MX7D core voltage?
>
> The sw1a regulator supplies the cpu0 and cpu1 cores. The PFUZE3000 SW1A limit
> for this design is typically around 1.475V, and the absolute maximum rating
> for the i.MX7D ARM cores is usually around 1.15V.
>
> If a driver scales the core voltage up to 3.3V based on these boundaries,
> could this result in hardware damage?

Please double check this one?

Frank

>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787586961.git.stefano.r@variscite.com?part=2
>