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> - 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
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 |
> + 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
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
> 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
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
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 |
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
© 2016 - 2025 Red Hat, Inc.