[PATCH 0/5] arm64: dts: freescale: Add IMX-AUD-IO daughter board support

[PATCH 0/5] arm64: dts: freescale: Add IMX-AUD-IO daughter board support

[Chancel Liu]

This patch series adds support for the IMX-AUD-IO daughter board[1] on
the i.MX95 19x19 EVK and i.MX952 EVK platforms.

IMX-AUD-IO is an audio I/O expansion board that can be connected to the
base board through a physically present I/O connector. Add a new
fsl,io-connector Device Tree binding to describe such connector which
acts as a nexus that exposes a constrained subset of GPIO, clock, PWM
and interrupt resources to the daughter board via fixed electrical
wiring. All actual hardware providers remain on the base board.

Also update the EVK base Device Trees to describe the connector and
required board-level resources. Add a DTS overlay to enable the
IMX-AUD-IO board.

The approach used here is inspired by the discussion[2] where a
connector is described as a nexus mapping board-level resources. One
important difference in this case is that the IMX-AUD-IO daughter board
is not a hot-pluggable device. The board is connected to the connector
before boot and remains present for the lifetime of the system. As a
result, the connector is modeled to describe fixed, boot-time hardware
wiring rather than runtime attachment or hot.

[1]https://www.nxp.com/part/IMX-AUD-IO
[2]https://lore.kernel.org/linux-devicetree/20250902105710.00512c6d@booty/

Chancel Liu (5):
  clk: Add support for clock nexus dt bindings
  dt-bindings: connector: Add fsl,io-connector binding
  arm64: dts: freescale: imx95-19x19-evk: Add IMX-AUD-IO board support
  arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board support
  arm64: dts: freescale: Add common DTS overlay for IMX-AUD-IO daughter
    board

 .../bindings/connector/fsl,io-connector.yaml  | 94 +++++++++++++++++++
 arch/arm64/boot/dts/freescale/Makefile        |  4 +
 arch/arm64/boot/dts/freescale/imx-aud-io.dtso | 58 ++++++++++++
 .../boot/dts/freescale/imx95-19x19-evk.dts    | 53 ++++++++++-
 arch/arm64/boot/dts/freescale/imx952-evk.dts  | 68 +++++++++++++-
 drivers/clk/clk.c                             |  4 +-
 6 files changed, 275 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx-aud-io.dtso

--
2.50.1

[PATCH 1/5] clk: Add support for clock nexus dt bindings

[Chancel Liu]

Platforms can have a standardized connector/expansion slot that exposes
signals like clocks to expansion boards in an SoC agnostic way.

The support for nexus node has been added to handle those cases in
commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through
a nexus node"). This commit introduced of_parse_phandle_with_args_map()
to handle nexus nodes in a generic way. Currently the gpio subsystem
adopted the support in commit c11e6f0f04db ("gpio: Support gpio nexus dt
bindings") and pwm subsystem adopted the support in commit e71e46a6f19c4
("pwm: Add support for pwm nexus dt bindings").

Change the function call to use of_parse_phandle_with_args_map() that
parses the phandle lists of clocks to use the nexus variant. This
allows remapping phandles and their arguments through any number of
nexus nodes and end up with the actual clock provider being used.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
 drivers/clk/clk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 048adfa86a5d..4240f059bec2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -5206,8 +5206,8 @@ static int of_parse_clkspec(const struct device_node *np, int index,
 		 */
 		if (name)
 			index = of_property_match_string(np, "clock-names", name);
-		ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
-						 index, out_args);
+		ret = of_parse_phandle_with_args_map(np, "clocks", "clock",
+						     index, out_args);
 		if (!ret)
 			break;
 		if (name && index >= 0)
-- 
2.50.1

[PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Chancel Liu]

The NXP I/O connector represents a physically present I/O connector on
the base board. It acts as a nexus that exposes a constrained set of
I/O resources, such as GPIOs, clocks, PWMs and interrupts, through
fixed electrical wiring. All actual hardware providers reside on the
base board. The connector node only defines index-based mappings to
those providers.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
 .../bindings/connector/fsl,io-connector.yaml  | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/connector/fsl,io-connector.yaml

diff --git a/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
new file mode 100644
index 000000000000..8b5038a2332e
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/connector/fsl,io-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP I/O Connector
+
+maintainers:
+  - Frank Li <Frank.li@nxp.com>
+  - Chancel Liu <chancel.liu@nxp.com>
+
+description:
+  The NXP I/O connector represents a physically present I/O connector on the
+  base board. It acts as a nexus that exposes a constrained set of I/O
+  resources, such as GPIOs, clocks, PWMs and interrupts, through fixed
+  electrical wiring. All actual hardware providers reside on the base board.
+  The connector node only defines index-based mappings to those providers.
+
+properties:
+  compatible:
+    const: fsl,io-connector
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    const: 2
+
+  gpio-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+  gpio-map-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  gpio-map-pass-thru:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  '#clock-cells':
+    const: 1
+
+  clock-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+  clock-map-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  clock-map-pass-thru:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  pwm-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+  pwm-map-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  pwm-map-pass-thru:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  '#address-cells':
+    const: 0
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+    const: 2
+
+  interrupt-map: true
+
+  interrupt-map-mask: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    connector {
+        compatible = "fsl,io-connector";
+        gpio-controller;
+        #gpio-cells = <2>;
+        gpio-map = <0 0 &gpio1 8 1>;
+        gpio-map-mask = <0xff 0x0>;
+        gpio-map-pass-thru = <0x0 0x1>;
+        #clock-cells = <1>;
+        clock-map = <0 &clk 1>;
+        #address-cells = <0>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+        interrupt-map-mask = <0xff 0x0>;
+        interrupt-map = <0 0 &gpio2 27 IRQ_TYPE_LEVEL_LOW>;
+    };
-- 
2.50.1

[PATCH 3/5] arm64: dts: freescale: imx95-19x19-evk: Add IMX-AUD-IO board support

[Chancel Liu]

IMX-AUD-IO is a daughter board which can be connected to i.MX95 19x19
EVK through a physical connector. This connector is described as a
fsl,io-connector connector to expose a constrained subset of GPIO and
clock resources to daughter board using fixed electrical wiring.

Also add required regulator, sound CPU DAI and I2C bus configuration to
support IMX-AUD-IO on this base board.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
 .../boot/dts/freescale/imx95-19x19-evk.dts    | 53 ++++++++++++++++++-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index 041fd838fabb..f9b53df85396 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -43,6 +43,17 @@ aliases {
 		serial4 = &lpuart5;
 	};
 
+	aud_io_conn: aud-io-connector {
+		compatible = "fsl,io-connector";
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-map = <0 0 &i2c6_pcal6416 8 1>;
+		gpio-map-mask = <0xff 0x0>;
+		gpio-map-pass-thru = <0x0 0x1>;
+		#clock-cells = <1>;
+		clock-map = <0 &scmi_clk IMX95_CLK_SAI2>;
+	};
+
 	bt_sco_codec: audio-codec-bt-sco {
 		#sound-dai-cells = <1>;
 		compatible = "linux,bt-sco";
@@ -94,7 +105,7 @@ flexcan2_phy: can-phy1 {
 		standby-gpios = <&i2c4_gpio_expander_21 3 GPIO_ACTIVE_LOW>;
 	};
 
-	reg_vref_1v8: regulator-1p8v {
+	aud_io_reg_1v8: reg_vref_1v8: regulator-1p8v {
 		compatible = "regulator-fixed";
 		regulator-max-microvolt = <1800000>;
 		regulator-min-microvolt = <1800000>;
@@ -108,6 +119,22 @@ reg_3p3v: regulator-3p3v {
 		regulator-name = "+V3.3_SW";
 	};
 
+	aud_io_reg_3v3: regulator-aud-io-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "aud-io-3v3";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		gpio = <&i2c6_pcal6416 11 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	aud_io_reg_5v: regulator-aud-io-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "aud-io-5v";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+	};
+
 	reg_audio_pwr: regulator-audio-pwr {
 		compatible = "regulator-fixed";
 		regulator-name = "audio-pwr";
@@ -382,7 +409,7 @@ i2c5_pcal6408: gpio@21 {
 	};
 };
 
-&lpi2c6 {
+aud_io_i2c: &lpi2c6 {
 	clock-frequency = <100000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_lpi2c6>;
@@ -588,6 +615,28 @@ &sai1 {
 	status = "okay";
 };
 
+aud_io_cpu: &sai2 {
+	#sound-dai-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai2>;
+	clocks = <&scmi_clk IMX95_CLK_BUSNETCMIX>, <&dummy>,
+		 <&scmi_clk IMX95_CLK_SAI2>, <&dummy>,
+		 <&dummy>, <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+		 <&scmi_clk IMX95_CLK_AUDIOPLL2>;
+	clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
+	assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX95_CLK_SAI2>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>,
+			       <393216000>, <361267200>, <12288000>;
+	fsl,sai-mclk-direction-output;
+	fsl,sai-asynchronous;
+};
+
 &sai3 {
 	#sound-dai-cells = <0>;
 	pinctrl-names = "default";
-- 
2.50.1

[PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board support

[Chancel Liu]

IMX-AUD-IO is a daughter board which can be connected to i.MX952 EVK
through a physical connector. This connector is described as a
fsl,io-connector connector to expose a constrained subset of GPIO and
clock resources to daughter board using fixed electrical wiring.

Also add required regulator, sound CPU DAI and I2C bus configuration to
support IMX-AUD-IO on this base board.

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx952-evk.dts | 68 +++++++++++++++++++-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx952-evk.dts b/arch/arm64/boot/dts/freescale/imx952-evk.dts
index 62d1c1c7c501..bb1d8d5f5fcf 100644
--- a/arch/arm64/boot/dts/freescale/imx952-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx952-evk.dts
@@ -43,6 +43,17 @@ aliases {
 		spi6 = &lpspi7;
 	};
 
+	aud_io_conn: aud-io-connector {
+		compatible = "fsl,io-connector";
+		gpio-controller;
+		#gpio-cells = <2>;
+		gpio-map = <0 0 &pcal6416 8 1>;
+		gpio-map-mask = <0xff 0x0>;
+		gpio-map-pass-thru = <0x0 0x1>;
+		#clock-cells = <1>;
+		clock-map = <0 &scmi_clk IMX952_CLK_SAI2>;
+	};
+
 	bt_sco_codec: audio-codec-bt-sco {
 		#sound-dai-cells = <1>;
 		compatible = "linux,bt-sco";
@@ -114,13 +125,29 @@ reg_1p8v: regulator-1p8v {
 		regulator-name = "+V1.8_SW";
 	};
 
-	reg_vref_1v8: regulator-adc-vref {
+	aud_io_reg_1v8: reg_vref_1v8: regulator-adc-vref {
 		compatible = "regulator-fixed";
 		regulator-name = "vref_1v8";
 		regulator-min-microvolt = <1800000>;
 		regulator-max-microvolt = <1800000>;
 	};
 
+	aud_io_reg_3v3: regulator-aud-io-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "aud-io-3v3";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		gpio = <&pcal6416 11 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	aud_io_reg_5v: regulator-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "aud-io-5v";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+	};
+
 	reg_audio_pwr: regulator-audio-pwr {
 		compatible = "regulator-fixed";
 		regulator-name = "audio-pwr";
@@ -323,7 +350,7 @@ i2c4_pcal6408: gpio@21 {
 	};
 };
 
-&lpi2c6 {
+aud_io_i2c: &lpi2c6 {
 	clock-frequency = <100000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_lpi2c6>;
@@ -468,6 +495,27 @@ &sai1 {
 	status = "okay";
 };
 
+aud_io_cpu: &sai2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai2>;
+	clocks = <&scmi_clk IMX952_CLK_BUSNETCMIX>, <&clk_dummy>,
+		 <&scmi_clk IMX952_CLK_SAI2>, <&clk_dummy>,
+		 <&clk_dummy>, <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+		 <&scmi_clk IMX952_CLK_AUDIOPLL2>;
+	clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
+	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX952_CLK_SAI2>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>,
+			       <393216000>, <361267200>, <12288000>;
+	fsl,sai-mclk-direction-output;
+	fsl,sai-asynchronous;
+};
+
 &sai3 {
 	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
 			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
@@ -688,6 +736,22 @@ IMX952_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_13		0x51e
 		>;
 	};
 
+	pinctrl_sai2: sai2grp {
+		fsl,pins = <
+			IMX952_PAD_ENET2_MDIO__NETCMIX_TOP_SAI2_RX_BCLK		0x31e
+			IMX952_PAD_ENET2_MDC__NETCMIX_TOP_SAI2_RX_SYNC		0x31e
+			IMX952_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_0	0x31e
+			IMX952_PAD_ENET2_TD2__NETCMIX_TOP_SAI2_RX_DATA_1	0x31e
+			IMX952_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK		0x31e
+			IMX952_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC	0x31e
+			IMX952_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_0	0x31e
+			IMX952_PAD_ENET2_RXC__NETCMIX_TOP_SAI2_TX_DATA_1	0x31e
+			IMX952_PAD_ENET2_RD0__NETCMIX_TOP_SAI2_TX_DATA_2	0x31e
+			IMX952_PAD_ENET2_RD1__NETCMIX_TOP_SAI2_TX_DATA_3	0x31e
+			IMX952_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK		0x31e
+		>;
+	};
+
 	pinctrl_sai3: sai3grp {
 		fsl,pins = <
 			IMX952_PAD_GPIO_IO17__WAKEUPMIX_TOP_SAI3_MCLK			0x31e
-- 
2.50.1

[PATCH 5/5] arm64: dts: freescale: Add common DTS overlay for IMX-AUD-IO daughter board

[Chancel Liu]

Add common DTS overlay for the IMX-AUD-IO daughter board[1] which
connects to the base board through a PCIe X8 slot.

This board features a CS42888 codec providing 2 microphone inputs, 2
line inputs and 6 channels audio output capability.

[1]https://www.nxp.com/part/IMX-AUD-IO

Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
---
 arch/arm64/boot/dts/freescale/Makefile        |  4 ++
 arch/arm64/boot/dts/freescale/imx-aud-io.dtso | 58 +++++++++++++++++++
 2 files changed, 62 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx-aud-io.dtso

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 0a4dabac5de4..7258740bfa23 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -545,11 +545,15 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie0-ep.dtb
 imx95-19x19-evk-pcie0-ep-dtbs += imx95-19x19-evk.dtb imx-pcie0-ep.dtbo
 imx95-19x19-evk-pcie1-ep-dtbs += imx95-19x19-evk.dtb imx-pcie1-ep.dtbo
 dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-pcie0-ep.dtb imx95-19x19-evk-pcie1-ep.dtb
+imx95-19x19-evk-aud-io-dtbs += imx95-19x19-evk.dtb imx-aud-io.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-aud-io.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-libra-rdk-fpsc.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-verdin-evk.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx952-evk.dtb
+imx952-evk-aud-io-dtbs += imx952-evk.dtb imx-aud-io.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx952-evk-aud-io.dtb
 
 imx8mm-kontron-dl-dtbs			:= imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
 imx8mm-kontron-bl-lte-dtbs		:= imx8mm-kontron-bl.dtb imx8mm-kontron-bl-lte.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx-aud-io.dtso b/arch/arm64/boot/dts/freescale/imx-aud-io.dtso
new file mode 100644
index 000000000000..77fd0aebd96b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx-aud-io.dtso
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common Device Tree for the IMX-AUD-IO daughter board[1].
+ * It connects to the baseboard through a PCIe X8 slot.
+ *
+ * [1]https://www.nxp.com/part/IMX-AUD-IO
+ *
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+	aud-io-sound-cs42888 {
+		compatible = "fsl,imx-audio-card";
+		model = "imx-cs42888";
+
+		pri-dai-link {
+			link-name = "cs42888";
+			format = "i2s";
+			fsl,mclk-equal-bclk;
+
+			codec {
+				sound-dai = <&audio_io_codec>;
+			};
+
+			cpu {
+				sound-dai = <&aud_io_cpu>;
+			};
+
+		};
+	};
+};
+
+&aud_io_i2c {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	audio_io_codec: codec@48 {
+		compatible = "cirrus,cs42888";
+		reg = <0x48>;
+		clocks = <&aud_io_conn 0>;
+		clock-names = "mclk";
+		VA-supply = <&aud_io_reg_5v>;
+		VD-supply = <&aud_io_reg_3v3>;
+		VLS-supply = <&aud_io_reg_1v8>;
+		VLC-supply = <&aud_io_reg_1v8>;
+		#sound-dai-cells = <0>;
+		reset-gpios = <&aud_io_conn 0 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&aud_io_cpu {
+	status = "okay";
+};
-- 
2.50.1

RE: [PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board support

[Bough Chen]

> -----Original Message-----
> From: Chancel Liu <chancel.liu@nxp.com>
> Sent: 2026年5月9日 10:49
> To: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; Frank Li
> <frank.li@nxp.com>; s.hauer@pengutronix.de; festevam@gmail.com;
> mturquette@baylibre.com; sboyd@kernel.org
> Cc: kernel@pengutronix.de; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-clk@vger.kernel.org
> Subject: [PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board
> support
> 
> IMX-AUD-IO is a daughter board which can be connected to i.MX952 EVK
> through a physical connector. This connector is described as a fsl,io-connector
> connector to expose a constrained subset of GPIO and clock resources to
> daughter board using fixed electrical wiring.
> 
> Also add required regulator, sound CPU DAI and I2C bus configuration to support
> IMX-AUD-IO on this base board.
> 
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/imx952-evk.dts | 68 +++++++++++++++++++-
>  1 file changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> index 62d1c1c7c501..bb1d8d5f5fcf 100644
> --- a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> @@ -43,6 +43,17 @@ aliases {
>  		spi6 = &lpspi7;
>  	};
> 
> +	aud_io_conn: aud-io-connector {
> +		compatible = "fsl,io-connector";
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		gpio-map = <0 0 &pcal6416 8 1>;
> +		gpio-map-mask = <0xff 0x0>;
> +		gpio-map-pass-thru = <0x0 0x1>;

According to the include/dt-bindings/gpio/gpio.h, there 6 bits definition for GPIO flags, here you just pass through bit 0, should it better to use the following value:
gpio-map-pass-thru = <0x0 0x3f>;

Regards
Haibo Chen
> +		#clock-cells = <1>;
> +		clock-map = <0 &scmi_clk IMX952_CLK_SAI2>;
> +	};
> +
>  	bt_sco_codec: audio-codec-bt-sco {
>  		#sound-dai-cells = <1>;
>  		compatible = "linux,bt-sco";
> @@ -114,13 +125,29 @@ reg_1p8v: regulator-1p8v {
>  		regulator-name = "+V1.8_SW";
>  	};
> 
> -	reg_vref_1v8: regulator-adc-vref {
> +	aud_io_reg_1v8: reg_vref_1v8: regulator-adc-vref {
>  		compatible = "regulator-fixed";
>  		regulator-name = "vref_1v8";
>  		regulator-min-microvolt = <1800000>;
>  		regulator-max-microvolt = <1800000>;
>  	};
> 
> +	aud_io_reg_3v3: regulator-aud-io-3v3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "aud-io-3v3";
> +		regulator-max-microvolt = <3300000>;
> +		regulator-min-microvolt = <3300000>;
> +		gpio = <&pcal6416 11 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +	};
> +
> +	aud_io_reg_5v: regulator-5v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "aud-io-5v";
> +		regulator-max-microvolt = <5000000>;
> +		regulator-min-microvolt = <5000000>;
> +	};
> +
>  	reg_audio_pwr: regulator-audio-pwr {
>  		compatible = "regulator-fixed";
>  		regulator-name = "audio-pwr";
> @@ -323,7 +350,7 @@ i2c4_pcal6408: gpio@21 {
>  	};
>  };
> 
> -&lpi2c6 {
> +aud_io_i2c: &lpi2c6 {
>  	clock-frequency = <100000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_lpi2c6>;
> @@ -468,6 +495,27 @@ &sai1 {
>  	status = "okay";
>  };
> 
> +aud_io_cpu: &sai2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_sai2>;
> +	clocks = <&scmi_clk IMX952_CLK_BUSNETCMIX>, <&clk_dummy>,
> +		 <&scmi_clk IMX952_CLK_SAI2>, <&clk_dummy>,
> +		 <&clk_dummy>, <&scmi_clk IMX952_CLK_AUDIOPLL1>,
> +		 <&scmi_clk IMX952_CLK_AUDIOPLL2>;
> +	clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
> +	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
> +			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
> +			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
> +			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
> +			  <&scmi_clk IMX952_CLK_SAI2>;
> +	assigned-clock-parents = <0>, <0>, <0>, <0>,
> +				 <&scmi_clk IMX952_CLK_AUDIOPLL1>;
> +	assigned-clock-rates = <3932160000>, <3612672000>,
> +			       <393216000>, <361267200>, <12288000>;
> +	fsl,sai-mclk-direction-output;
> +	fsl,sai-asynchronous;
> +};
> +
>  &sai3 {
>  	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
>  			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
> @@ -688,6 +736,22 @@
> IMX952_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_13		0x51e
>  		>;
>  	};
> 
> +	pinctrl_sai2: sai2grp {
> +		fsl,pins = <
> +			IMX952_PAD_ENET2_MDIO__NETCMIX_TOP_SAI2_RX_BCLK
> 	0x31e
> +			IMX952_PAD_ENET2_MDC__NETCMIX_TOP_SAI2_RX_SYNC
> 	0x31e
> +			IMX952_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_0
> 	0x31e
> +			IMX952_PAD_ENET2_TD2__NETCMIX_TOP_SAI2_RX_DATA_1
> 	0x31e
> +			IMX952_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK
> 	0x31e
> +			IMX952_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC
> 	0x31e
> +
> 	IMX952_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_0
> 	0x31e
> +			IMX952_PAD_ENET2_RXC__NETCMIX_TOP_SAI2_TX_DATA_1
> 	0x31e
> +			IMX952_PAD_ENET2_RD0__NETCMIX_TOP_SAI2_TX_DATA_2
> 	0x31e
> +			IMX952_PAD_ENET2_RD1__NETCMIX_TOP_SAI2_TX_DATA_3
> 	0x31e
> +			IMX952_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK
> 	0x31e
> +		>;
> +	};
> +
>  	pinctrl_sai3: sai3grp {
>  		fsl,pins = <
>  			IMX952_PAD_GPIO_IO17__WAKEUPMIX_TOP_SAI3_MCLK
> 	0x31e
> --
> 2.50.1
> 

RE: [PATCH 1/5] clk: Add support for clock nexus dt bindings

[Chancel Liu]

Hi all,

Please ignore this patch.

I noticed that the same change was already posted earlier by Miquel Raynal
as part of his series ([PATCH 10/16] clk: Add support for clock nexus dt bindings):
 https://lkml.org/lkml/2026/3/27/1983

To avoid duplication, noise, and wasted review time, I will drop my patch.

Regarding the questions raised by the sashiko review (e.g. assigned-clocks /
assigned-clock-parents behavior with nexus nodes), this aligns with the
ongoing discussion in Miquel's thread so I suggest we continue the discussion there.

Sorry for the noise.

Regards, 
Chancel Liu

> Platforms can have a standardized connector/expansion slot that exposes
> signals like clocks to expansion boards in an SoC agnostic way.
> 
> The support for nexus node has been added to handle those cases in
> commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through
> a nexus node"). This commit introduced of_parse_phandle_with_args_map()
> to handle nexus nodes in a generic way. Currently the gpio subsystem
> adopted the support in commit c11e6f0f04db ("gpio: Support gpio nexus dt
> bindings") and pwm subsystem adopted the support in commit
> e71e46a6f19c4
> ("pwm: Add support for pwm nexus dt bindings").
> 
> Change the function call to use of_parse_phandle_with_args_map() that
> parses the phandle lists of clocks to use the nexus variant. This
> allows remapping phandles and their arguments through any number of
> nexus nodes and end up with the actual clock provider being used.
> 
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
>  drivers/clk/clk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 048adfa86a5d..4240f059bec2 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -5206,8 +5206,8 @@ static int of_parse_clkspec(const struct
> device_node *np, int index,
>  		 */
>  		if (name)
>  			index = of_property_match_string(np, "clock-names",
> name);
> -		ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
> -						 index, out_args);
> +		ret = of_parse_phandle_with_args_map(np, "clocks", "clock",
> +						     index, out_args);
>  		if (!ret)
>  			break;
>  		if (name && index >= 0)
> --
> 2.50.1

RE: [PATCH 4/5] arm64: dts: freescale: imx952-evk: Add IMX-AUD-IO board support

[Chancel Liu]

> > diff --git a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> > index 62d1c1c7c501..bb1d8d5f5fcf 100644
> > --- a/arch/arm64/boot/dts/freescale/imx952-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx952-evk.dts
> > @@ -43,6 +43,17 @@ aliases {
> >  		spi6 = &lpspi7;
> >  	};
> >
> > +	aud_io_conn: aud-io-connector {
> > +		compatible = "fsl,io-connector";
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		gpio-map = <0 0 &pcal6416 8 1>;
> > +		gpio-map-mask = <0xff 0x0>;
> > +		gpio-map-pass-thru = <0x0 0x1>;
> 
> According to the include/dt-bindings/gpio/gpio.h, there 6 bits definition for
> GPIO flags, here you just pass through bit 0, should it better to use the
> following value:
> gpio-map-pass-thru = <0x0 0x3f>;
> 
> Regards
> Haibo Chen

Good point. 
For this connector on the base board, the intention is to only pass
through the polarity flag (bit0) in the GPIO flags cell. Other standard
GPIO flags are fixed on the base board side and won't be propagated
across this connector. 

To avoid confusion, I'll add a short comment in the DT to explicitly
document that only the polarity bit is passed for GPIO flags on this
connector.

Regards, 
Chancel Liu

Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Krzysztof Kozlowski]

On Sat, May 09, 2026 at 11:48:43AM +0900, Chancel Liu wrote:
> The NXP I/O connector represents a physically present I/O connector on
> the base board. It acts as a nexus that exposes a constrained set of
> I/O resources, such as GPIOs, clocks, PWMs and interrupts, through
> fixed electrical wiring. All actual hardware providers reside on the
> base board. The connector node only defines index-based mappings to
> those providers.
> 
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
>  .../bindings/connector/fsl,io-connector.yaml  | 94 +++++++++++++++++++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
> 
> diff --git a/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
> new file mode 100644
> index 000000000000..8b5038a2332e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/fsl,io-connector.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/connector/fsl,io-connector.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP I/O Connector
> +
> +maintainers:
> +  - Frank Li <Frank.li@nxp.com>
> +  - Chancel Liu <chancel.liu@nxp.com>
> +
> +description:
> +  The NXP I/O connector represents a physically present I/O connector on the
> +  base board. It acts as a nexus that exposes a constrained set of I/O
> +  resources, such as GPIOs, clocks, PWMs and interrupts, through fixed
> +  electrical wiring. All actual hardware providers reside on the base board.
> +  The connector node only defines index-based mappings to those providers.
> +
> +properties:
> +  compatible:
> +    const: fsl,io-connector

Everything is IO. Everything is connector, so your compatible does not
match requirements from writing bindings.

> +
> +  gpio-controller: true
> +
> +  '#gpio-cells':
> +    const: 2
> +
> +  gpio-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix

You do not need to redefine the types. You need constraints, though.

> +
> +  gpio-map-mask:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  gpio-map-pass-thru:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  '#clock-cells':
> +    const: 1
> +
> +  clock-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> +  clock-map-mask:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  clock-map-pass-thru:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array

I do not see these defined anywhere. I also checked cover letter for
references for pulls to dtschema.


> +
> +  pwm-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> +  pwm-map-mask:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  pwm-map-pass-thru:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  '#address-cells':
> +    const: 0
> +
> +  interrupt-controller: true
> +
> +  "#interrupt-cells":

Use consistent quotes.

> +    const: 2
> +
> +  interrupt-map: true
> +
> +  interrupt-map-mask: true
> +
> +required:
> +  - compatible

You need to require the properties. You have a FIXED connector, so it
has fixed set of features.

Best regards,
Krzysztof

RE: Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Chancel Liu]

> > +description:
> > +  The NXP I/O connector represents a physically present I/O connector
> > +on the
> > +  base board. It acts as a nexus that exposes a constrained set of
> > +I/O
> > +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> > +fixed
> > +  electrical wiring. All actual hardware providers reside on the base board.
> > +  The connector node only defines index-based mappings to those
> providers.
> > +
> > +properties:
> > +  compatible:
> > +    const: fsl,io-connector
> 
> Everything is IO. Everything is connector, so your compatible does not match
> requirements from writing bindings.
> 

Yes, this compatible is too generic. I will rename the compatible to
fsl,aud-io-connector.

> > +
> > +  gpio-controller: true
> > +
> > +  '#gpio-cells':
> > +    const: 2
> > +
> > +  gpio-map:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> 
> You do not need to redefine the types. You need constraints, though.
> 

OK. I will add proper constraints.

> > +
> > +  gpio-map-mask:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  gpio-map-pass-thru:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  '#clock-cells':
> > +    const: 1
> > +
> > +  clock-map:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > +  clock-map-mask:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  clock-map-pass-thru:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> 
> I do not see these defined anywhere. I also checked cover letter for
> references for pulls to dtschema.
> 
 
Nexus nodes are already in the device-tree specification：
https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
For reference, current kernel has supported it:
* Nexus OF support:
commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
* GPIO adoption:
commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
* PWM adoption:
commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
Clock adoption is ongoing:
https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/

> > +
> > +  pwm-map:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > +  pwm-map-mask:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  pwm-map-pass-thru:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  '#address-cells':
> > +    const: 0
> > +
> > +  interrupt-controller: true
> > +
> > +  "#interrupt-cells":
> 
> Use consistent quotes.
> 

I will fix it in next revision.

> > +    const: 2
> > +
> > +  interrupt-map: true
> > +
> > +  interrupt-map-mask: true
> > +
> > +required:
> > +  - compatible
> 
> You need to require the properties. You have a FIXED connector, so it has
> fixed set of features.
> 
> Best regards,
> Krzysztof

I will make gpio related properties required because they are mandatory
for DT. Clock and interrupt mappings are board/configuration dependent
so I prefer to use dependentRequired when they are present.

Regards, 
Chancel Liu

Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Krzysztof Kozlowski]

On 18/05/2026 06:18, Chancel Liu wrote:
>>> +description:
>>> +  The NXP I/O connector represents a physically present I/O connector
>>> +on the
>>> +  base board. It acts as a nexus that exposes a constrained set of
>>> +I/O
>>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
>>> +fixed
>>> +  electrical wiring. All actual hardware providers reside on the base board.
>>> +  The connector node only defines index-based mappings to those
>> providers.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    const: fsl,io-connector
>>
>> Everything is IO. Everything is connector, so your compatible does not match
>> requirements from writing bindings.
>>
> 
> Yes, this compatible is too generic. I will rename the compatible to
> fsl,aud-io-connector.

aud is not much better. Which boards have it? What's the pinout? What's
standard? Is it described anywhere? If so, provide reference to spec/docs.

> 
>>> +
>>> +  gpio-controller: true
>>> +
>>> +  '#gpio-cells':
>>> +    const: 2
>>> +
>>> +  gpio-map:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
>>
>> You do not need to redefine the types. You need constraints, though.
>>
> 
> OK. I will add proper constraints.
> 
>>> +
>>> +  gpio-map-mask:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> +  gpio-map-pass-thru:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> +  '#clock-cells':
>>> +    const: 1
>>> +
>>> +  clock-map:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
>>> +
>>> +  clock-map-mask:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> +  clock-map-pass-thru:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>
>> I do not see these defined anywhere. I also checked cover letter for
>> references for pulls to dtschema.
>>
>  
> Nexus nodes are already in the device-tree specification：
> https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
> For reference, current kernel has supported it:
> * Nexus OF support:
> commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
> * GPIO adoption:
> commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
> * PWM adoption:
> commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
> Clock adoption is ongoing:
> https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/

DT spec only mentions nexuses, but it is only a spec. Each property from
the spec must be defined in dtschema or kernel bindings.

I do not see any dependency mentioned in the cover letter, so how do you
think we can figure out where is this definition of clock nexus?


Best regards,
Krzysztof

RE: Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Chancel Liu]

> >>> +description:
> >>> +  The NXP I/O connector represents a physically present I/O
> >>> +connector on the
> >>> +  base board. It acts as a nexus that exposes a constrained set of
> >>> +I/O
> >>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> >>> +fixed
> >>> +  electrical wiring. All actual hardware providers reside on the base
> board.
> >>> +  The connector node only defines index-based mappings to those
> >> providers.
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    const: fsl,io-connector
> >>
> >> Everything is IO. Everything is connector, so your compatible does
> >> not match requirements from writing bindings.
> >>
> >
> > Yes, this compatible is too generic. I will rename the compatible to
> > fsl,aud-io-connector.
> 
> aud is not much better. Which boards have it? What's the pinout? What's
> standard? Is it described anywhere? If so, provide reference to spec/docs.
>

This is not an industry standard electrical interface. This connector
is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
"i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
audio board connection through which IMX-AUD-IO card is connected. The
detailed user manual (UM12022) is listed as official documentation[2],
but it is behind an NXP login, so it is not suitable as a public
reference for upstream. Therefore I list it here to illustrate it's
mechanism:

+-----------------------------+                      
|        Base Board           |                      
|   +-----+      +---------+  |           +---------+
|   | SPI +------+         |  |           |         |
|   +-----+      |         |  | GPIO MAP  |         |
|                |         +--|-----------+         |
|   +-----+      |         |  |           |         |
|   | I2C +------+         |  |           |         |
|   +-----+      |         |  | CLOCK MAP |  AUD-IO |
|                |connector+--|-----------+   CARD  |
|   +-----+      |         |  |           |         |
|   | I2S +------+         |  |           |         |
|   +-----+      |         |  |           |         |
|                |         |  | INT MAP   |         |
|   +-----+      |         +--|-----------+         |
|   | I/O +------+         |  |           |         |
|   +-----+      +---------+  |           +---------+
+-----------------------------+                      

[1]https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19
[2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html

> >
> >>> +
> >>> +  gpio-controller: true
> >>> +
> >>> +  '#gpio-cells':
> >>> +    const: 2
> >>> +
> >>> +  gpio-map:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>
> >> You do not need to redefine the types. You need constraints, though.
> >>
> >
> > OK. I will add proper constraints.
> >
> >>> +
> >>> +  gpio-map-mask:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  gpio-map-pass-thru:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  '#clock-cells':
> >>> +    const: 1
> >>> +
> >>> +  clock-map:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> >>> +
> >>> +  clock-map-mask:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>> +
> >>> +  clock-map-pass-thru:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>
> >> I do not see these defined anywhere. I also checked cover letter for
> >> references for pulls to dtschema.
> >>
> >
> > Nexus nodes are already in the device-tree specification：
> > https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
> > For reference, current kernel has supported it:
> > * Nexus OF support:
> > commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists
> > through a nexus node")
> > * GPIO adoption:
> > commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
> > * PWM adoption:
> > commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
> > Clock adoption is ongoing:
> > https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
>
> DT spec only mentions nexuses, but it is only a spec. Each property from
> the spec must be defined in dtschema or kernel bindings.
> 
> I do not see any dependency mentioned in the cover letter, so how do you
> think we can figure out where is this definition of clock nexus?
> 
> 

I initially tried to add support for clock nexus dt bindings in patch 1,
but I noticed there is already an ongoing series doing the same thing.
([PATCH 10/16] clk: Add support for clock nexus dt bindings). Since that
work is in progress, I think it's better not duplicate it here.

I think we can add a dedicated binding defining the clock nexus
properties(#clock-cells, clock-map, clock-map-mask, clock-map-pass-thru),
in reference of existing pwm-nexus-node.yaml.

In the next revision I will also update the cover letter to explicitly
mention that clock nexus support is ongoing.

> Best regards,
> Krzysztof

Regards, 
Chancel Liu

Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Krzysztof Kozlowski]

On Tue, May 19, 2026 at 02:56:24AM +0000, Chancel Liu wrote:
> > >>> +description:
> > >>> +  The NXP I/O connector represents a physically present I/O
> > >>> +connector on the
> > >>> +  base board. It acts as a nexus that exposes a constrained set of
> > >>> +I/O
> > >>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> > >>> +fixed
> > >>> +  electrical wiring. All actual hardware providers reside on the base
> > board.
> > >>> +  The connector node only defines index-based mappings to those
> > >> providers.
> > >>> +
> > >>> +properties:
> > >>> +  compatible:
> > >>> +    const: fsl,io-connector
> > >>
> > >> Everything is IO. Everything is connector, so your compatible does
> > >> not match requirements from writing bindings.
> > >>
> > >
> > > Yes, this compatible is too generic. I will rename the compatible to
> > > fsl,aud-io-connector.
> > 
> > aud is not much better. Which boards have it? What's the pinout? What's
> > standard? Is it described anywhere? If so, provide reference to spec/docs.
> >
> 
> This is not an industry standard electrical interface. This connector

Then if you do not have standard, then you have board specific layouts
thus you need board-specific compatibles. You can use fallbacks. Generic
fallback could work, but both io-connector and aud-io-connector are just
too generic. Every connector is "connector" and "io", thus absolutely
anything can be "io-connector". "aud" improves it only a bit, thus
honestly I would go with board specific fallback as well.

> is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
> "i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
> audio board connection through which IMX-AUD-IO card is connected. The
> detailed user manual (UM12022) is listed as official documentation[2],
> but it is behind an NXP login, so it is not suitable as a public
> reference for upstream. Therefore I list it here to illustrate it's
> mechanism:
> 
> +-----------------------------+                      
> |        Base Board           |                      
> |   +-----+      +---------+  |           +---------+
> |   | SPI +------+         |  |           |         |
> |   +-----+      |         |  | GPIO MAP  |         |
> |                |         +--|-----------+         |
> |   +-----+      |         |  |           |         |
> |   | I2C +------+         |  |           |         |
> |   +-----+      |         |  | CLOCK MAP |  AUD-IO |
> |                |connector+--|-----------+   CARD  |
> |   +-----+      |         |  |           |         |
> |   | I2S +------+         |  |           |         |
> |   +-----+      |         |  |           |         |
> |                |         |  | INT MAP   |         |
> |   +-----+      |         +--|-----------+         |
> |   | I/O +------+         |  |           |         |
> |   +-----+      +---------+  |           +---------+
> +-----------------------------+                      
> 
> [1]https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19
> [2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html

Best regards,
Krzysztof

RE: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Chancel Liu (OSS)]

> > > >>> +description:
> > > >>> +  The NXP I/O connector represents a physically present I/O
> > > >>> +connector on the
> > > >>> +  base board. It acts as a nexus that exposes a constrained set
> of
> > > >>> +I/O
> > > >>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> > > >>> +fixed
> > > >>> +  electrical wiring. All actual hardware providers reside on the
> base
> > > board.
> > > >>> +  The connector node only defines index-based mappings to those
> > > >> providers.
> > > >>> +
> > > >>> +properties:
> > > >>> +  compatible:
> > > >>> +    const: fsl,io-connector
> > > >>
> > > >> Everything is IO. Everything is connector, so your compatible does
> > > >> not match requirements from writing bindings.
> > > >>
> > > >
> > > > Yes, this compatible is too generic. I will rename the compatible to
> > > > fsl,aud-io-connector.
> > >
> > > aud is not much better. Which boards have it? What's the pinout?
> What's
> > > standard? Is it described anywhere? If so, provide reference to
> spec/docs.
> > >
> >
> > This is not an industry standard electrical interface. This connector
> 
> Then if you do not have standard, then you have board specific layouts
> thus you need board-specific compatibles. You can use fallbacks. Generic
> fallback could work, but both io-connector and aud-io-connector are just
> too generic. Every connector is "connector" and "io", thus absolutely
> anything can be "io-connector". "aud" improves it only a bit, thus
> honestly I would go with board specific fallback as well.
> 

How about board specific + common fallback compatible like this:
  compatible:
    items:
      - enum:
          - fsl,imx95-19x19-evk-aud-io-connector
          - fsl,imx952-evk-aud-io-connector
      - const: fsl,imx-aud-io-connector
Since the daughter board is named “IMX-AUD-IO” in publicly available
documentation, common compatible clearly indicates that this connector
is intended for that.

Also, I want to talk about the topic of generic connector. It's a common
design that daughter board is connected to base board through a
connector. This connector more often acts as a nexus that exposes a
constrained subset of GPIO, clock, PWM and interrupt resources to the
daughter board. Can we document this kind of connector as a generic
binding?

Regards, 
Chancel Liu

> > is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
> > "i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
> > audio board connection through which IMX-AUD-IO card is connected. The
> > detailed user manual (UM12022) is listed as official documentation[2],
> > but it is behind an NXP login, so it is not suitable as a public
> > reference for upstream. Therefore I list it here to illustrate it's
> > mechanism:
> >
> > +-----------------------------+
> > |        Base Board           |
> > |   +-----+      +---------+  |           +---------+
> > |   | SPI +------+         |  |           |         |
> > |   +-----+      |         |  | GPIO MAP  |         |
> > |                |         +--|-----------+         |
> > |   +-----+      |         |  |           |         |
> > |   | I2C +------+         |  |           |         |
> > |   +-----+      |         |  | CLOCK MAP |  AUD-IO |
> > |                |connector+--|-----------+   CARD  |
> > |   +-----+      |         |  |           |         |
> > |   | I2S +------+         |  |           |         |
> > |   +-----+      |         |  |           |         |
> > |                |         |  | INT MAP   |         |
> > |   +-----+      |         +--|-----------+         |
> > |   | I/O +------+         |  |           |         |
> > |   +-----+      +---------+  |           +---------+
> > +-----------------------------+
> >
> > [1]https://www.nxp.com/design/design-center/development-boards-and-
> designs/IMX95LPD5EVK-19
> > [2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html
> 
> Best regards,
> Krzysztof

Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Krzysztof Kozlowski]

On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>> +description:
>>>>>>> +  The NXP I/O connector represents a physically present I/O
>>>>>>> +connector on the
>>>>>>> +  base board. It acts as a nexus that exposes a constrained set
>> of
>>>>>>> +I/O
>>>>>>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
>>>>>>> +fixed
>>>>>>> +  electrical wiring. All actual hardware providers reside on the
>> base
>>>> board.
>>>>>>> +  The connector node only defines index-based mappings to those
>>>>>> providers.
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    const: fsl,io-connector
>>>>>>
>>>>>> Everything is IO. Everything is connector, so your compatible does
>>>>>> not match requirements from writing bindings.
>>>>>>
>>>>>
>>>>> Yes, this compatible is too generic. I will rename the compatible to
>>>>> fsl,aud-io-connector.
>>>>
>>>> aud is not much better. Which boards have it? What's the pinout?
>> What's
>>>> standard? Is it described anywhere? If so, provide reference to
>> spec/docs.
>>>>
>>>
>>> This is not an industry standard electrical interface. This connector
>>
>> Then if you do not have standard, then you have board specific layouts
>> thus you need board-specific compatibles. You can use fallbacks. Generic
>> fallback could work, but both io-connector and aud-io-connector are just
>> too generic. Every connector is "connector" and "io", thus absolutely
>> anything can be "io-connector". "aud" improves it only a bit, thus
>> honestly I would go with board specific fallback as well.
>>
> 
> How about board specific + common fallback compatible like this:
>   compatible:
>     items:
>       - enum:
>           - fsl,imx95-19x19-evk-aud-io-connector
>           - fsl,imx952-evk-aud-io-connector
>       - const: fsl,imx-aud-io-connector
> Since the daughter board is named “IMX-AUD-IO” in publicly available

I don't think it is named like that.

git grep -i imx-aud-io

> documentation, common compatible clearly indicates that this connector
> is intended for that.
> 
> Also, I want to talk about the topic of generic connector. It's a common
> design that daughter board is connected to base board through a
> connector. This connector more often acts as a nexus that exposes a
> constrained subset of GPIO, clock, PWM and interrupt resources to the
> daughter board. Can we document this kind of connector as a generic
> binding?

So this binding is the connector between carrier and some addon? Then
you don't get a compatible for that at all, because it is not necessary,
not useful and NEVER used. Do you see socket LGA "connector" bindings? No.


Best regards,
Krzysztof

Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding

[Frank Li]

On Wed, May 20, 2026 at 09:08:42AM +0200, Krzysztof Kozlowski wrote:
> On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
> >>>>>>> +description:
> >>>>>>> +  The NXP I/O connector represents a physically present I/O
> >>>>>>> +connector on the
> >>>>>>> +  base board. It acts as a nexus that exposes a constrained set
> >> of
> >>>>>>> +I/O
> >>>>>>> +  resources, such as GPIOs, clocks, PWMs and interrupts, through
> >>>>>>> +fixed
> >>>>>>> +  electrical wiring. All actual hardware providers reside on the
> >> base
> >>>> board.
> >>>>>>> +  The connector node only defines index-based mappings to those
> >>>>>> providers.
> >>>>>>> +
> >>>>>>> +properties:
> >>>>>>> +  compatible:
> >>>>>>> +    const: fsl,io-connector
> >>>>>>
> >>>>>> Everything is IO. Everything is connector, so your compatible does
> >>>>>> not match requirements from writing bindings.
> >>>>>>
> >>>>>
> >>>>> Yes, this compatible is too generic. I will rename the compatible to
> >>>>> fsl,aud-io-connector.
> >>>>
> >>>> aud is not much better. Which boards have it? What's the pinout?
> >> What's
> >>>> standard? Is it described anywhere? If so, provide reference to
> >> spec/docs.
> >>>>
> >>>
> >>> This is not an industry standard electrical interface. This connector
> >>
> >> Then if you do not have standard, then you have board specific layouts
> >> thus you need board-specific compatibles. You can use fallbacks. Generic
> >> fallback could work, but both io-connector and aud-io-connector are just
> >> too generic. Every connector is "connector" and "io", thus absolutely
> >> anything can be "io-connector". "aud" improves it only a bit, thus
> >> honestly I would go with board specific fallback as well.
> >>
> >
> > How about board specific + common fallback compatible like this:
> >   compatible:
> >     items:
> >       - enum:
> >           - fsl,imx95-19x19-evk-aud-io-connector
> >           - fsl,imx952-evk-aud-io-connector
> >       - const: fsl,imx-aud-io-connector
> > Since the daughter board is named “IMX-AUD-IO” in publicly available
>
> I don't think it is named like that.
>
> git grep -i imx-aud-io
>
> > documentation, common compatible clearly indicates that this connector
> > is intended for that.
> >
> > Also, I want to talk about the topic of generic connector. It's a common
> > design that daughter board is connected to base board through a
> > connector. This connector more often acts as a nexus that exposes a
> > constrained subset of GPIO, clock, PWM and interrupt resources to the
> > daughter board. Can we document this kind of connector as a generic
> > binding?
>
> So this binding is the connector between carrier and some addon? Then
> you don't get a compatible for that at all, because it is not necessary,
> not useful and NEVER used. Do you see socket LGA "connector" bindings? No.

Not exactly. Any connector connects a carrier board with an add-on board.
The key point here is that this connector type is reused across different
boards, even though it is not an industry-standard connector. Both the
signal definitions and the mechanical layout are defined.

The same add-on boards can therefore be reused across different base boards
that use this type of connector.

There are also GPIO mappings involved. For example, pin 1 on the connector
may represent reset-gpios, but it could be connected to GPIO0 on board A
and GPIO1 on board B.

Without a connector definition layer, this would create an N × M
combination problem. The Nexus node discussion already covered this topic:
https://osseu2025.sched.com/event/25Vrw

An LGA socket is a CPU socket, where the signals are completely transparent
to software, so it is not a good comparison. A PCIe M.2 Key-M/E connector
would be a more appropriate comparison.

Frank

>
>
> Best regards,
> Krzysztof