* [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
2025-09-18 12:19 [PATCH v2 0/3] Mainline Protonic PRT8ML board Jonas Rebmann
@ 2025-09-18 12:19 ` Jonas Rebmann
2025-09-18 15:32 ` Frank Li
` (2 more replies)
2025-09-18 12:19 ` [PATCH v2 2/3] dt-bindings: arm: fsl: Add Protonic PRT8ML Jonas Rebmann
` (2 subsequent siblings)
3 siblings, 3 replies; 18+ messages in thread
From: Jonas Rebmann @ 2025-09-18 12:19 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team
Cc: Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
2025-09-18 12:19 ` [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property Jonas Rebmann
@ 2025-09-18 15:32 ` Frank Li
2025-09-22 17:33 ` Rob Herring (Arm)
2025-09-22 17:35 ` Vladimir Oltean
2 siblings, 0 replies; 18+ messages in thread
From: Frank Li @ 2025-09-18 15:32 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team,
Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
2025-09-18 12:19 ` [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property Jonas Rebmann
2025-09-18 15:32 ` Frank Li
@ 2025-09-22 17:33 ` Rob Herring (Arm)
2025-09-22 17:35 ` Vladimir Oltean
2 siblings, 0 replies; 18+ messages in thread
From: Rob Herring (Arm) @ 2025-09-22 17:33 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Paolo Abeni, Jakub Kicinski, Conor Dooley, Krzysztof Kozlowski,
Shawn Guo, Mark Brown, Vladimir Oltean, netdev, Shengjiu Wang,
Vladimir Oltean, Fabio Estevam, Eric Dumazet, devicetree,
linux-kernel, Liam Girdwood, Pengutronix Kernel Team,
David S. Miller, linux-arm-kernel, Sascha Hauer, Andrew Lunn, imx,
linux-sound
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
2025-09-18 12:19 ` [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property Jonas Rebmann
2025-09-18 15:32 ` Frank Li
2025-09-22 17:33 ` Rob Herring (Arm)
@ 2025-09-22 17:35 ` Vladimir Oltean
2 siblings, 0 replies; 18+ messages in thread
From: Vladimir Oltean @ 2025-09-22 17:35 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, netdev,
devicetree, linux-kernel, linux-sound, imx, linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v2 2/3] dt-bindings: arm: fsl: Add Protonic PRT8ML
2025-09-18 12:19 [PATCH v2 0/3] Mainline Protonic PRT8ML board Jonas Rebmann
2025-09-18 12:19 ` [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property Jonas Rebmann
@ 2025-09-18 12:19 ` Jonas Rebmann
2025-09-18 12:19 ` [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board Jonas Rebmann
2025-09-18 14:50 ` [PATCH v2 0/3] Mainline " Rob Herring (Arm)
3 siblings, 0 replies; 18+ messages in thread
From: Jonas Rebmann @ 2025-09-18 12:19 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team
Cc: Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 12:19 [PATCH v2 0/3] Mainline Protonic PRT8ML board Jonas Rebmann
2025-09-18 12:19 ` [PATCH v2 1/3] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property Jonas Rebmann
2025-09-18 12:19 ` [PATCH v2 2/3] dt-bindings: arm: fsl: Add Protonic PRT8ML Jonas Rebmann
@ 2025-09-18 12:19 ` Jonas Rebmann
2025-09-18 14:14 ` Andrew Lunn
2025-09-18 14:18 ` Andrew Lunn
2025-09-18 14:50 ` [PATCH v2 0/3] Mainline " Rob Herring (Arm)
3 siblings, 2 replies; 18+ messages in thread
From: Jonas Rebmann @ 2025-09-18 12:19 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team
Cc: Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, Jonas Rebmann, David Jander, Lucas Stach,
Oleksij Rempel
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
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 12:19 ` [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board Jonas Rebmann
@ 2025-09-18 14:14 ` Andrew Lunn
2025-09-18 14:51 ` David Jander
2025-09-18 14:18 ` Andrew Lunn
1 sibling, 1 reply; 18+ messages in thread
From: Andrew Lunn @ 2025-09-18 14:14 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, Vladimir Oltean, netdev,
devicetree, linux-kernel, linux-sound, imx, linux-arm-kernel,
David Jander, Lucas Stach, Oleksij Rempel
> + 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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 14:14 ` Andrew Lunn
@ 2025-09-18 14:51 ` David Jander
2025-09-18 15:04 ` Andrew Lunn
0 siblings, 1 reply; 18+ messages in thread
From: David Jander @ 2025-09-18 14:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jonas Rebmann, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team,
Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, Lucas Stach, Oleksij Rempel
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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 14:51 ` David Jander
@ 2025-09-18 15:04 ` Andrew Lunn
2025-09-18 15:33 ` David Jander
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Lunn @ 2025-09-18 15:04 UTC (permalink / raw)
To: David Jander
Cc: Jonas Rebmann, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team,
Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, Lucas Stach, Oleksij Rempel
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 15:04 ` Andrew Lunn
@ 2025-09-18 15:33 ` David Jander
2025-09-19 5:08 ` Oleksij Rempel
0 siblings, 1 reply; 18+ messages in thread
From: David Jander @ 2025-09-18 15:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jonas Rebmann, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team,
Vladimir Oltean, netdev, devicetree, linux-kernel, linux-sound,
imx, linux-arm-kernel, Lucas Stach, Oleksij Rempel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 15:33 ` David Jander
@ 2025-09-19 5:08 ` Oleksij Rempel
2025-09-19 7:31 ` David Jander
0 siblings, 1 reply; 18+ messages in thread
From: Oleksij Rempel @ 2025-09-19 5:08 UTC (permalink / raw)
To: David Jander
Cc: Andrew Lunn, Jonas Rebmann, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Shengjiu Wang, Shawn Guo, Sascha Hauer, Fabio Estevam,
Pengutronix Kernel Team, Vladimir Oltean, netdev, devicetree,
linux-kernel, linux-sound, imx, linux-arm-kernel, Lucas Stach
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 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-19 5:08 ` Oleksij Rempel
@ 2025-09-19 7:31 ` David Jander
0 siblings, 0 replies; 18+ messages in thread
From: David Jander @ 2025-09-19 7:31 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Andrew Lunn, Jonas Rebmann, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Shengjiu Wang, Shawn Guo, Sascha Hauer, Fabio Estevam,
Pengutronix Kernel Team, Vladimir Oltean, netdev, devicetree,
linux-kernel, linux-sound, imx, linux-arm-kernel, Lucas Stach
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 12:19 ` [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board Jonas Rebmann
2025-09-18 14:14 ` Andrew Lunn
@ 2025-09-18 14:18 ` Andrew Lunn
2025-09-18 15:01 ` Jonas Rebmann
1 sibling, 1 reply; 18+ messages in thread
From: Andrew Lunn @ 2025-09-18 14:18 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, Vladimir Oltean, netdev,
devicetree, linux-kernel, linux-sound, imx, linux-arm-kernel,
David Jander, Lucas Stach, Oleksij Rempel
> - 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board
2025-09-18 14:18 ` Andrew Lunn
@ 2025-09-18 15:01 ` Jonas Rebmann
0 siblings, 0 replies; 18+ messages in thread
From: Jonas Rebmann @ 2025-09-18 15:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Shengjiu Wang, Shawn Guo, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, Vladimir Oltean, netdev,
devicetree, linux-kernel, linux-sound, imx, linux-arm-kernel,
David Jander, Lucas Stach, Oleksij Rempel
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 |
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/3] Mainline Protonic PRT8ML board
2025-09-18 12:19 [PATCH v2 0/3] Mainline Protonic PRT8ML board Jonas Rebmann
` (2 preceding siblings ...)
2025-09-18 12:19 ` [PATCH v2 3/3] arm64: dts: add Protonic PRT8ML board Jonas Rebmann
@ 2025-09-18 14:50 ` Rob Herring (Arm)
3 siblings, 0 replies; 18+ messages in thread
From: Rob Herring (Arm) @ 2025-09-18 14:50 UTC (permalink / raw)
To: Jonas Rebmann
Cc: Mark Brown, Shengjiu Wang, David S. Miller, devicetree,
Andrew Lunn, David Jander, Lucas Stach, Liam Girdwood,
Paolo Abeni, Fabio Estevam, Vladimir Oltean, Eric Dumazet,
Sascha Hauer, Krzysztof Kozlowski, netdev, Conor Dooley,
Jakub Kicinski, Shawn Guo, linux-kernel, imx, Vladimir Oltean,
linux-sound, Pengutronix Kernel Team, Oleksij Rempel,
linux-arm-kernel
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#
^ permalink raw reply [flat|nested] 18+ messages in thread