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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Contradictory microphone routing disables analog capture on WM8904.
- [Medium] Contradictory `no-1-8-v` property in usdhc1 disables UHS SD card speeds despite hardware support.
--

commit 5821f4e873dc44e1cfd4f21d2d7e03f1e0298edd
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 and is available in
multiple configurations and hardware revisions.

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-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.

> 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?

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