Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Frank.Li@oss.nxp.com
Cc: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	imx@lists.linux.dev, robh@kernel.org, conor+dt@kernel.org,
	Frank.Li@kernel.org
Subject: Re: [PATCH v3 5/7] arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller
Date: Tue, 20 Oct 2026 23:04:08 +0000	[thread overview]
Message-ID: <sashiko-outbox-179591@kernel.org> (raw)
In-Reply-To: <20261020-dxl_lcdif-v3-5-adc944659e14@nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64: dts: imx8dxl-evk: spi0_mux and m4_debug_mux driven low on probe
--

commit a3a65e29ad3fd8c46c72a9be8f8c719076ef18d5
Author: Frank Li <Frank.Li@nxp.com>

arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller

This commit adds four gpio-mux controllers and a pinctrl-multiplexer node
to describe the onboard signal multiplexer on imx8dxl-evk, and removes the
regulator-m2uart1sel node.

> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> index 0ede0c7ed422c..0ee2a028ebff6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> @@ -97,14 +97,68 @@ vdevbuffer: memory-vdevbuffer@90400000 {
>  		};
>  	};
>  
> -	m2_uart1_sel: regulator-m2uart1sel {
> -		compatible = "regulator-fixed";
> -		regulator-min-microvolt = <3300000>;
> -		regulator-max-microvolt = <3300000>;
> -		regulator-name = "m2_uart1_sel";
> -		gpio = <&pca6416_1 6 GPIO_ACTIVE_HIGH>;
> -		enable-active-high;
> -		regulator-always-on;
> +	m4_debug_mux: mux-controller-0 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pca6416_1 3 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	spi3_mux: mux-controller-1 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pca6416_1 4 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	uart1_mux: mux-controller-2 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pca6416_1 6 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	spi0_mux: mux-controller-3 {
> +		compatible = "gpio-mux";
> +		#mux-control-cells = <0>;
> +		#mux-state-cells = <1>;
> +		mux-gpios = <&pca6416_1 7 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	pinctrl-gpiomux {
> +		compatible = "pinctrl-multiplexer";
> +
> +		m4_debug_fun: cm4-uart-grp {
> +			mux-states = <&m4_debug_mux 1>;
> +		};
> +
> +		spi0_fun: spi0-grp {
> +			mux-states = <&spi0_mux 1>;
> +		};
> +
> +		spi3_fun: spi3-grp {
> +			mux-states = <&spi3_mux 1>;
> +		};
> +
> +		uart1_fun: uart1-grp {
> +			mux-states = <&uart1_mux 1>;
> +		};
> +
> +		lcd_0_fun: lcd0-grp {
> +			mux-states = <&spi0_mux 0>;
> +		};
> +
> +		lcd_1_fun: lcd1-grp {
> +			mux-states = <&spi3_mux 0>;
> +		};
> +
> +		lcd_2_fun: lcd2-grp {
> +			mux-states = <&uart1_mux 0>;
> +		};
> +
> +		lcd_3_fun: lcd3-grp {
> +			mux-states = <&m4_debug_mux 0>;
> +		};
>  	};
>  
>  	mux3_en: regulator-0 {

[ ... ]

> @@ -658,7 +712,7 @@ &cm40_intmux {
>  
>  &cm40_lpuart {
>  	pinctrl-names = "default";
> -	pinctrl-0 = <&pinctrl_cm40_lpuart>;
> +	pinctrl-0 = <&pinctrl_cm40_lpuart>, <&m4_debug_fun>;
>  	status = "disabled";
>  };
>  

[Severity: High]
Does adding spi0_mux and m4_debug_mux without an active consumer or
idle-state = <1> cause those muxes to be driven low (state 0, lcd_0_fun
and lcd_3_fun) at boot instead of keeping the hardware pull-up default
(state 1)?

When mux_gpio_probe() in drivers/mux/gpio.c probes each gpio-mux node, it
requests the mux gpios as outputs initialized low (state 0):

drivers/mux/gpio.c:mux_gpio_probe() {
	...
	mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
	...
}

Because neither spi0_mux nor m4_debug_mux specifies idle-state = <1>, both
lines remain driven low unless an enabled device selects spi0_fun or
m4_debug_fun:

1. In arch/arm64/boot/dts/freescale/imx8dxl-evk.dts, spi0_fun is defined in
pinctrl-gpiomux, but has no consumer. Meanwhile, &sai0 is enabled (used by
sound-bt-sco) and muxes its signals onto the spi0 pads via pinctrl_sai0
without referencing spi0_fun:

	&sai0 {
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_sai0>;
		...
		status = "okay";
	};

	pinctrl_sai0: sai0grp {
		fsl,pins = <
			IMX8DXL_SPI0_CS0_ADMA_SAI0_RXD		0x06000060
			IMX8DXL_SPI0_CS1_ADMA_SAI0_RXC		0x06000040
			IMX8DXL_SPI0_SCK_ADMA_SAI0_TXC		0x06000060
			IMX8DXL_SPI0_SDI_ADMA_SAI0_TXD		0x06000060
			IMX8DXL_SPI0_SDO_ADMA_SAI0_TXFS		0x06000040
		>;
	};

2. For m4_debug_mux, m4_debug_fun is only attached to &cm40_lpuart, which has
status = "disabled", while &adc0 and imx8dxl-cm4 are enabled and share the
pads controlled by m4_debug_mux (&pca6416_1 3).

Should &sai0 include <&spi0_fun> in pinctrl-0, and should the mux controllers
specify idle-state = <1> (or have m4_debug_fun selected by an enabled
consumer) so that sai0 and the m4 / adc0 signals are not disconnected on
probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020-dxl_lcdif-v3-0-adc944659e14@nxp.com?part=5

  reply	other threads:[~2026-10-20 23:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 20:12 [PATCH v3 0/7] display: lcdif: imx: add display support for imx8dxl and imx8qxp Frank.Li
2026-10-20 20:12 ` [PATCH v3 1/7] dt-bindings: lcdif: add compatible string for i.MX8QXP and i.MX8DXL Frank.Li
2026-10-21  8:20   ` Liu Ying
2026-10-20 20:12 ` [PATCH v3 2/7] dt-bindings: display: simple: Add waiken,101wx001-wct Frank.Li
2026-10-21  8:22   ` Liu Ying
2026-10-20 20:12 ` [PATCH v3 3/7] drm/panel: simple: Add Waiken WKS101WX001-WCT panel support Frank.Li
2026-10-21  8:25   ` Liu Ying
2026-10-20 20:12 ` [PATCH v3 4/7] arm64: dts: imx8-ss-dma: Add lcdif support for i.MX8QXP and i.MX8DXL Frank.Li
2026-10-20 22:50   ` sashiko-bot
2026-10-20 20:12 ` [PATCH v3 5/7] arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller Frank.Li
2026-10-20 23:04   ` sashiko-bot [this message]
2026-10-21  8:29   ` Liu Ying
2026-10-20 20:12 ` [PATCH v3 6/7] arm64: dts: imx8dxl-evk: Move ACM MCLK pin to ACM pinctrl Frank.Li
2026-10-21  8:31   ` Liu Ying
2026-10-20 20:12 ` [PATCH v3 7/7] arm64: dts: imx8dxl-evk: add lcdif overlay Frank.Li
2026-10-20 23:31   ` sashiko-bot
2026-10-21  8:34   ` Liu Ying

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=sashiko-outbox-179591@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=Frank.Li@oss.nxp.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imx@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox