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
next prev parent 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