[PATCH v2 0/3] Mainline Protonic PRT8ML board

[PATCH v2 0/3] Mainline Protonic PRT8ML board

[Jonas Rebmann]

This series adds the Protonic PRT8ML device tree as well as some minor
corrections to the devicetree bindings used.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
Changes in v2:
- Dropped "ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI
  properties", applied to broonie/sound for-next (Thanks, Mark)
- Updated description of the reset-gpios property in sja1105 binding to
  address the issues of connecting this pin to GPIO (Thanks, Vladimir)
- Added the fec, switch and phy for RJ45 onboard ethernet after
  successful testing
- Consistently use interrupts-extended
- Link to v1: https://lore.kernel.org/r/20250910-imx8mp-prt8ml-v1-0-fd04aed15670@pengutronix.de

---
Jonas Rebmann (3):
      dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
      dt-bindings: arm: fsl: Add Protonic PRT8ML
      arm64: dts: add Protonic PRT8ML board

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 .../devicetree/bindings/net/dsa/nxp,sja1105.yaml   |   9 +
 arch/arm64/boot/dts/freescale/Makefile             |   1 +
 arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts    | 500 +++++++++++++++++++++
 4 files changed, 511 insertions(+)
---
base-commit: ea21fa34164c9ea0a2a5b8714c7e36f54c7fb46e
change-id: 20250701-imx8mp-prt8ml-01be34684659

Best regards,
--  
Jonas Rebmann <jre@pengutronix.de>

[PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Jonas Rebmann]

Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
reset pin, rendering reset-gpios a valid property for all of the
nxp,sja1105 family.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 9432565f4f5d..e9dd914b0734 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -32,6 +32,15 @@ properties:
   reg:
     maxItems: 1
 
+  reset-gpios:
+    description:
+      A GPIO connected to the active-low RST_N pin of the SJA1105. Note that
+      reset of this chip is performed via SPI and the RST_N pin must be wired
+      to satisfy the power-up sequence documented in "SJA1105PQRS Application
+      Hints" (AH1704) sec. 2.4.4. Connecting the SJA1105 RST_N pin to a GPIO is
+      therefore discouraged.
+    maxItems: 1
+
   spi-cpha: true
   spi-cpol: true
 

-- 
2.51.0.178.g2462961280

Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Frank Li]

On Thu, Sep 18, 2025 at 02:19:44PM +0200, Jonas Rebmann wrote:
> Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> reset pin, rendering reset-gpios a valid property for all of the
> nxp,sja1105 family.
>
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> ---
>  Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> index 9432565f4f5d..e9dd914b0734 100644
> --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> @@ -32,6 +32,15 @@ properties:
>    reg:
>      maxItems: 1
>
> +  reset-gpios:
> +    description:
> +      A GPIO connected to the active-low RST_N pin of the SJA1105. Note that
> +      reset of this chip is performed via SPI and the RST_N pin must be wired
> +      to satisfy the power-up sequence documented in "SJA1105PQRS Application
> +      Hints" (AH1704) sec. 2.4.4. Connecting the SJA1105 RST_N pin to a GPIO is
> +      therefore discouraged.
> +    maxItems: 1
> +
>    spi-cpha: true
>    spi-cpol: true
>
>
> --
> 2.51.0.178.g2462961280
>

Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Rob Herring (Arm)]

On Thu, 18 Sep 2025 14:19:44 +0200, Jonas Rebmann wrote:
> Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> reset pin, rendering reset-gpios a valid property for all of the
> nxp,sja1105 family.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Vladimir Oltean]

On Thu, Sep 18, 2025 at 02:19:44PM +0200, Jonas Rebmann wrote:
> Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> reset pin, rendering reset-gpios a valid property for all of the
> nxp,sja1105 family.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---

Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com>

[PATCH v2 2/3] dt-bindings: arm: fsl: Add Protonic PRT8ML

[Jonas Rebmann]

Add DT compatible string for Protonic PRT8ML board.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 00cdf490b062..b135f6360733 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1106,6 +1106,7 @@ properties:
               - gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board
               - gateworks,imx8mp-gw82xx-2x # i.MX8MP Gateworks Board
               - gocontroll,moduline-display # GOcontroll Moduline Display controller
+              - prt,prt8ml             # Protonic PRT8ML
               - skov,imx8mp-skov-basic # SKOV i.MX8MP baseboard without frontplate
               - skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
               - skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel

-- 
2.51.0.178.g2462961280

[PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Jonas Rebmann]

Add devicetree for the Protonic PRT8ML.

The board is similar to the Protonic PRT8MM but i.MX8MP based.

Some features have been removed as the drivers haven't been mainlined
yet or other issues where encountered:
 - Stepper motors to be controlled using motion control subsystem
 - MIPI/DSI to eDP USB alt-mode
 - Onboard T1 ethernet (10BASE-T1L+PoDL, 100BASE-T1+PoDL, 1000BASE-T1)

Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 arch/arm64/boot/dts/freescale/Makefile          |   1 +
 arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts | 500 ++++++++++++++++++++++++
 2 files changed, 501 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 525ef180481d..0c9abfa8d23d 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -228,6 +228,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-nitrogen-smarc-universal-board.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
 imx8mp-phyboard-pollux-rdk-no-eth-dtbs += imx8mp-phyboard-pollux-rdk.dtb imx8mp-phycore-no-eth.dtbo
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk-no-eth.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-prt8ml.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-basic.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts b/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts
new file mode 100644
index 000000000000..5d3b5d114804
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2020 Protonic Holland
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+
+/ {
+	model = "Protonic PRT8ML";
+	compatible = "prt,prt8ml", "fsl,imx8mp";
+
+	chosen {
+		stdout-path = &uart4;
+	};
+
+	pcie_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <100000000>;
+	};
+
+	pcie_refclk_oe: pcie0-refclk-oe {
+		compatible = "gpio-gate-clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcie_refclk>;
+		clocks = <&pcie_refclk>;
+		#clock-cells = <0>;
+		enable-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&A53_0 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_1 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_2 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_3 {
+	cpu-supply = <&fan53555>;
+};
+
+&a53_opp_table {
+	opp-1200000000 {
+		opp-microvolt = <900000>;
+	};
+
+	opp-1600000000 {
+		opp-microvolt = <980000>;
+	};
+
+	/delete-node/ opp-1800000000;
+};
+
+&ecspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi2>;
+	cs-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH>;
+	/delete-property/ dmas;
+	/delete-property/ dma-names;
+	status = "okay";
+
+	switch@0 {
+		compatible = "nxp,sja1105q";
+		reg = <0>;
+		reset-gpios = <&gpio_exp_1 4 GPIO_ACTIVE_LOW>;
+		spi-cpha;
+		spi-max-frequency = <4000000>;
+		spi-rx-delay-us = <1>;
+		spi-tx-delay-us = <1>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@3 {
+				reg = <3>;
+				label = "rj45";
+				phy-handle = <&rj45_phy>;
+				phy-mode = "rgmii-id";
+			};
+
+			port@4 {
+				reg = <4>;
+				ethernet = <&fec>;
+				label = "cpu";
+				phy-mode = "rgmii-id";
+				rx-internal-delay-ps = <2000>;
+				tx-internal-delay-ps = <2000>;
+
+				fixed-link {
+					full-duplex;
+					speed = <100>;
+				};
+			};
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec>;
+	phy-mode = "rgmii"; /* switch inserts delay */
+	rx-internal-delay-ps = <0>;
+	tx-internal-delay-ps = <0>;
+	status = "okay";
+
+	fixed-link {
+		full-duplex;
+		speed = <100>;
+	};
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rj45_phy: ethernet-phy@2 {
+			reg = <2>;
+			reset-gpios = <&gpio_exp_1 1 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <80000>;
+		};
+	};
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	status = "okay";
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	ak5558: codec@10 {
+		compatible = "asahi-kasei,ak5558";
+		reg = <0x10>;
+		reset-gpios = <&gpio_exp_1 2 GPIO_ACTIVE_LOW>;
+	};
+
+	gpio_exp_1: gpio@25 {
+		compatible = "nxp,pca9571";
+		reg = <0x25>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	tps65987ddh_0: usb-pd@20 {
+		compatible = "ti,tps6598x";
+		reg = <0x20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tps65987ddh_0>;
+		interrupts-extended = <&gpio1 12 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	gpio_exp_2: gpio@25 {
+		compatible = "nxp,pca9571";
+		reg = <0x25>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		c0-hreset-hog {
+			gpio-hog;
+			gpios = <7 GPIO_ACTIVE_LOW>;
+			line-name = "c0-hreset";
+			output-low;
+		};
+
+		c1-hreset-hog {
+			gpio-hog;
+			gpios = <6 GPIO_ACTIVE_LOW>;
+			line-name = "c1-hreset";
+			output-low;
+		};
+	};
+
+	fan53555: regulator@60 {
+		compatible = "fcs,fan53555";
+		reg = <0x60>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_fan53555>;
+		regulator-name = "fan53555";
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <980000>;
+		regulator-always-on;
+		regulator-boot-on;
+		fcs,suspend-voltage-selector = <1>;
+	};
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ak4458: codec@11 {
+		compatible = "asahi-kasei,ak4458";
+		reg = <0x11>;
+		#sound-dai-cells = <0>;
+		reset-gpios = <&gpio_exp_2 5 GPIO_ACTIVE_LOW>;
+	};
+
+	tps65987ddh_1: usb-pd@20 {
+		compatible = "ti,tps6598x";
+		reg = <0x20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tps65987ddh_1>;
+		interrupts-extended = <&gpio1 15 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&lcdif1 {
+	status = "okay";
+};
+
+&snvs_pwrkey {
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usb3_0 {
+	status = "okay";
+};
+
+&usb3_1 {
+	status = "okay";
+};
+
+&usb3_phy0 {
+	status = "okay";
+};
+
+&usb3_phy1 {
+	status = "okay";
+};
+
+&usb_dwc3_0 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usb_dwc3_1 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	assigned-clocks = <&clk IMX8MP_CLK_USDHC2>;
+	assigned-clock-rates = <100000000>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+	assigned-clocks = <&clk IMX8MP_CLK_USDHC3_ROOT>;
+	assigned-clock-rates = <400000000>;
+	bus-width = <8>;
+	non-removable;
+	no-sdio;
+	no-sd;
+	status = "okay";
+};
+
+&wdog1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_ecspi2: ecspi2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_ECSPI2_SCLK__ECSPI2_SCLK		0x154
+			MX8MP_IOMUXC_ECSPI2_MOSI__ECSPI2_MOSI		0x154
+			MX8MP_IOMUXC_ECSPI2_MISO__ECSPI2_MISO		0x154
+			MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13		0x154
+		>;
+	};
+
+	pinctrl_fan53555: fan53555grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05		0x114
+		>;
+	};
+
+	pinctrl_fec: fecgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SAI1_RXD2__ENET1_MDC		0x3
+			MX8MP_IOMUXC_SAI1_RXD3__ENET1_MDIO		0x3
+			MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0		0x91
+			MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1		0x91
+			MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2		0x91
+			MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3		0x91
+			MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC		0x91
+			MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL	0x91
+			MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0		0x1f
+			MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1		0x1f
+			MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2		0x1f
+			MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3		0x1f
+			MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL	0x1f
+			MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC		0x1f
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SPDIF_RX__CAN1_RX		0x154
+			MX8MP_IOMUXC_SPDIF_TX__CAN1_TX		0x154
+		>;
+	};
+
+	pinctrl_flexcan2: flexcan2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART3_TXD__CAN2_RX		0x154
+			MX8MP_IOMUXC_UART3_RXD__CAN2_TX		0x154
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_ECSPI1_SCLK__I2C1_SCL	0x400000c3
+			MX8MP_IOMUXC_ECSPI1_MOSI__I2C1_SDA	0x400000c3
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL		0x400000c3
+			MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA		0x400000c3
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL		0x400000c3
+			MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA		0x400000c3
+		>;
+	};
+
+	pinctrl_pcie_refclk: pcierefclkgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART1_TXD__GPIO5_IO23	0xc6
+		>;
+	};
+
+	pinctrl_tps65987ddh_0: tps65987ddh_0grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12	0x1d0
+		>;
+	};
+
+	pinctrl_tps65987ddh_1: tps65987ddh_1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15	0x1d0
+		>;
+	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX		0x040
+			MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX		0x040
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x190
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d0
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d0
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d0
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d0
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d0
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x194
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d4
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d4
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d4
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d4
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d4
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x196
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d6
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d6
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d6
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d6
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d6
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12		0x0d4
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x190
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d0
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d0
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d0
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d0
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d0
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d0
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d0
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d0
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d0
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x190
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x194
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d4
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d4
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d4
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d4
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d4
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d4
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d4
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d4
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d4
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x194
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x196
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d6
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d6
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d6
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d6
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d6
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d6
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d6
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d6
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d6
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x196
+		>;
+	};
+
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B		0x166
+		>;
+	};
+};

-- 
2.51.0.178.g2462961280

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Andrew Lunn]

> +			port@4 {
> +				reg = <4>;
> +				ethernet = <&fec>;
> +				label = "cpu";
> +				phy-mode = "rgmii-id";
> +				rx-internal-delay-ps = <2000>;
> +				tx-internal-delay-ps = <2000>;
> +
> +				fixed-link {
> +					full-duplex;
> +					speed = <100>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec>;
> +	phy-mode = "rgmii"; /* switch inserts delay */
> +	rx-internal-delay-ps = <0>;
> +	tx-internal-delay-ps = <0>;
> +	status = "okay";
> +
> +	fixed-link {
> +		full-duplex;
> +		speed = <100>;
> +	};

You have an RGMII interface, but you run it at 100Mbps? That might be
worth a comment somewhere to explain why.

	Andrew

	

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[David Jander]

On Thu, 18 Sep 2025 16:14:28 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > +			port@4 {
> > +				reg = <4>;
> > +				ethernet = <&fec>;
> > +				label = "cpu";
> > +				phy-mode = "rgmii-id";
> > +				rx-internal-delay-ps = <2000>;
> > +				tx-internal-delay-ps = <2000>;
> > +
> > +				fixed-link {
> > +					full-duplex;
> > +					speed = <100>;
> > +				};
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&fec {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_fec>;
> > +	phy-mode = "rgmii"; /* switch inserts delay */
> > +	rx-internal-delay-ps = <0>;
> > +	tx-internal-delay-ps = <0>;
> > +	status = "okay";
> > +
> > +	fixed-link {
> > +		full-duplex;
> > +		speed = <100>;
> > +	};  
> 
> You have an RGMII interface, but you run it at 100Mbps? That might be
> worth a comment somewhere to explain why.

Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP
FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient
internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q
ignores these, leading to packet loss, which is obviously worse than
restricting this link to 100Mbps. Ironically both chips are from the same
manufacturer, yet are incompatible in this regard.

Best regards,

-- 
David Jander

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Andrew Lunn]

> Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP
> FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient
> internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q
> ignores these, leading to packet loss, which is obviously worse than
> restricting this link to 100Mbps. Ironically both chips are from the same
> manufacturer, yet are incompatible in this regard.

Thanks for the explanation. Maybe add a comment that the bandwidth is
limited due to the lack of flow control resulting in packet loss in
the FEC.

Anything which looks odd deserves a comment, otherwise somebody will
question it....

	Andrew

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[David Jander]

On Thu, 18 Sep 2025 17:04:55 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP
> > FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient
> > internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q
> > ignores these, leading to packet loss, which is obviously worse than
> > restricting this link to 100Mbps. Ironically both chips are from the same
> > manufacturer, yet are incompatible in this regard.  
> 
> Thanks for the explanation. Maybe add a comment that the bandwidth is
> limited due to the lack of flow control resulting in packet loss in
> the FEC.
>
> Anything which looks odd deserves a comment, otherwise somebody will
> question it....

Yes! This is a golden tip. Ironically what I said above is incorrect. Sorry
for the noise.

Ftr: I wrote this DT about 4 years ago, so my memory failed me, and a comment
in the code would have saved me this embarrassment ;-)

The comment above applies to the i.MX6 SoC's which had this limitation. On the
i.MX8MP we had a different problem that also caused the SJA1105Q not to work
reliably at 1000Mbps either. We haven't been able to find the issue, but so far
this switch hasn't been able to work at 1000Mbps reliable on any platform,
possibly for different reasons in each case.

Best regards,

-- 
David Jander

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Oleksij Rempel]

On Thu, Sep 18, 2025 at 05:33:47PM +0200, David Jander wrote:
> On Thu, 18 Sep 2025 17:04:55 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
> > > Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP
> > > FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient
> > > internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q
> > > ignores these, leading to packet loss, which is obviously worse than
> > > restricting this link to 100Mbps. Ironically both chips are from the same
> > > manufacturer, yet are incompatible in this regard.  
> > 
> > Thanks for the explanation. Maybe add a comment that the bandwidth is
> > limited due to the lack of flow control resulting in packet loss in
> > the FEC.
> >
> > Anything which looks odd deserves a comment, otherwise somebody will
> > question it....
> 
> Yes! This is a golden tip. Ironically what I said above is incorrect. Sorry
> for the noise.
> 
> Ftr: I wrote this DT about 4 years ago, so my memory failed me, and a comment
> in the code would have saved me this embarrassment ;-)
> 
> The comment above applies to the i.MX6 SoC's which had this limitation. On the
> i.MX8MP we had a different problem that also caused the SJA1105Q not to work
> reliably at 1000Mbps either. We haven't been able to find the issue, but so far
> this switch hasn't been able to work at 1000Mbps reliable on any platform,
> possibly for different reasons in each case.

May be it is doe to RGMII clock switching issue and the requirement to
have specific silence time for proper clock frequency detection on the
switch side?

Or it is just artifact from iMX6 platform and it should be retested?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[David Jander]

On Fri, 19 Sep 2025 07:08:45 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> On Thu, Sep 18, 2025 at 05:33:47PM +0200, David Jander wrote:
> > On Thu, 18 Sep 2025 17:04:55 +0200
> > Andrew Lunn <andrew@lunn.ch> wrote:
> >   
> > > > Yes, unfortunately the SJA1105Q does not support PAUSE frames, and the i.MX8MP
> > > > FEC isn't able to sustain 1000Mbps (only about 400ish) due to insufficient
> > > > internal bus bandwidth. It will generate PAUSE frames, but the SJA1105Q
> > > > ignores these, leading to packet loss, which is obviously worse than
> > > > restricting this link to 100Mbps. Ironically both chips are from the same
> > > > manufacturer, yet are incompatible in this regard.    
> > > 
> > > Thanks for the explanation. Maybe add a comment that the bandwidth is
> > > limited due to the lack of flow control resulting in packet loss in
> > > the FEC.
> > >
> > > Anything which looks odd deserves a comment, otherwise somebody will
> > > question it....  
> > 
> > Yes! This is a golden tip. Ironically what I said above is incorrect. Sorry
> > for the noise.
> > 
> > Ftr: I wrote this DT about 4 years ago, so my memory failed me, and a comment
> > in the code would have saved me this embarrassment ;-)
> > 
> > The comment above applies to the i.MX6 SoC's which had this limitation. On the
> > i.MX8MP we had a different problem that also caused the SJA1105Q not to work
> > reliably at 1000Mbps either. We haven't been able to find the issue, but so far
> > this switch hasn't been able to work at 1000Mbps reliable on any platform,
> > possibly for different reasons in each case.  
> 
> May be it is doe to RGMII clock switching issue and the requirement to
> have specific silence time for proper clock frequency detection on the
> switch side?

I doubt it is that, because it works well at 100Mbps still in RGMII mode, and
according to the documentation the delay line is active for all rates.

OTOH, this switch probably has some other issues related to the RXC delay
line. It is always the RX path (RX at the switch, TX at the MAC) that
randomly does not work.

OT (but still posting in case someone here knows something):
Coincidentally I am currently working on a different design with a SJA1105Q
switch connected to a LAN743X MAC. The complication is that this MAC cannot
disable the TXC (RXC at the switch) at all. Still working on this, but right
now it looks like not even with the RX delay line deactivated (doing the delay
at the MAC) is the switch working reliably (at 1000Mbps). Investigation still
on-going so take with grain of salt.

> Or it is just artifact from iMX6 platform and it should be retested?

I remember having tested it and it not working reliably, but that was 4 years
ago or so. Drivers have evolved since, so maybe it is worth testing again?

Best regards,

-- 
David Jander

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Andrew Lunn]

>  - Onboard T1 ethernet (10BASE-T1L+PoDL, 100BASE-T1+PoDL, 1000BASE-T1)

Are these PHYs connected to the switch? It just seems odd you have a
switch with only one port connected to the outside world.

	Andrew 

Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board

[Jonas Rebmann]

Hi Andrew,

On 2025-09-18 16:18, Andrew Lunn wrote:
>>   - Onboard T1 ethernet (10BASE-T1L+PoDL, 100BASE-T1+PoDL, 1000BASE-T1)
> 
> Are these PHYs connected to the switch? It just seems odd you have a
> switch with only one port connected to the outside world.

yes, the 10BASE-T1L+PoDL and 100BASE-T1+PoDL are. We didn't get to test
them, so I removed them from the devicetree.

Regards,
Jonas

-- 
Pengutronix e.K.                           | Jonas Rebmann               |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Re: [PATCH v2 0/3] Mainline Protonic PRT8ML board

[Rob Herring (Arm)]

On Thu, 18 Sep 2025 14:19:43 +0200, Jonas Rebmann wrote:
> This series adds the Protonic PRT8ML device tree as well as some minor
> corrections to the devicetree bindings used.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
> Changes in v2:
> - Dropped "ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI
>   properties", applied to broonie/sound for-next (Thanks, Mark)
> - Updated description of the reset-gpios property in sja1105 binding to
>   address the issues of connecting this pin to GPIO (Thanks, Vladimir)
> - Added the fec, switch and phy for RJ45 onboard ethernet after
>   successful testing
> - Consistently use interrupts-extended
> - Link to v1: https://lore.kernel.org/r/20250910-imx8mp-prt8ml-v1-0-fd04aed15670@pengutronix.de
> 
> ---
> Jonas Rebmann (3):
>       dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
>       dt-bindings: arm: fsl: Add Protonic PRT8ML
>       arm64: dts: add Protonic PRT8ML board
> 
>  Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
>  .../devicetree/bindings/net/dsa/nxp,sja1105.yaml   |   9 +
>  arch/arm64/boot/dts/freescale/Makefile             |   1 +
>  arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts    | 500 +++++++++++++++++++++
>  4 files changed, 511 insertions(+)
> ---
> base-commit: ea21fa34164c9ea0a2a5b8714c7e36f54c7fb46e
> change-id: 20250701-imx8mp-prt8ml-01be34684659
> 
> Best regards,
> --
> Jonas Rebmann <jre@pengutronix.de>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit ea21fa34164c9ea0a2a5b8714c7e36f54c7fb46e

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/freescale/' for 20250918-imx8mp-prt8ml-v2-0-3d84b4fe53de@pengutronix.de:

arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dtb: codec@11 (asahi-kasei,ak4458): '#sound-dai-cells' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/sound/asahi-kasei,ak4458.yaml#
arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dtb: isp@32e10000 (fsl,imx8mp-isp): 'power-domain-names' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/media/rockchip-isp1.yaml#
arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dtb: isp@32e10000 (fsl,imx8mp-isp): power-domains: [[77, 6], [77, 1]] is too long
	from schema $id: http://devicetree.org/schemas/media/rockchip-isp1.yaml#
arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dtb: isp@32e20000 (fsl,imx8mp-isp): 'power-domain-names' does not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/media/rockchip-isp1.yaml#
arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dtb: isp@32e20000 (fsl,imx8mp-isp): power-domains: [[77, 6], [77, 4]] is too long
	from schema $id: http://devicetree.org/schemas/media/rockchip-isp1.yaml#