Message ID | 20240317164850.32708-3-laurent.pinchart@ideasonboard.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Add DT bindings and device tree for Compulab SB-UCM-iMX8MPLUS | expand |
> +&eqos { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_eqos>; > + phy-mode = "rgmii-id"; > + phy-handle = <ðphy0>; > + > + mdio { > + compatible = "snps,dwmac-mdio"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */ > + ethphy0: ethernet-phy@0 { > + compatible = "ethernet-phy-ieee802.3-c22"; > + reg = <0>; > + eee-broken-1000t; > + }; Hi Laurent Do you happen to know what is broken with respect to EEE? It seems like a lot of IMX boards have this, so i suspect it is the MAC. Maybe we should be keying off the MAC compatible and disabling this in the ethernet driver rather than have every .dts file needing it?
On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote: > > +&eqos { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_eqos>; > > + phy-mode = "rgmii-id"; > > + phy-handle = <ðphy0>; > > + > > + mdio { > > + compatible = "snps,dwmac-mdio"; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + /* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */ > > + ethphy0: ethernet-phy@0 { > > + compatible = "ethernet-phy-ieee802.3-c22"; > > + reg = <0>; > > + eee-broken-1000t; > > + }; > > Hi Laurent > > Do you happen to know what is broken with respect to EEE? It seems > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe > we should be keying off the MAC compatible and disabling this in the > ethernet driver rather than have every .dts file needing it? I wonder if this could be cargo-cult. To be honest, I've copied it from the BSP and haven't investigated it. I've tried dropping that and haven't noticed any difference, but I'm not sure how I should test it properly.
On Sun, Mar 17, 2024 at 08:57:22PM +0200, Laurent Pinchart wrote: > On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote: > > > +&eqos { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&pinctrl_eqos>; > > > + phy-mode = "rgmii-id"; > > > + phy-handle = <ðphy0>; > > > + > > > + mdio { > > > + compatible = "snps,dwmac-mdio"; > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + /* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */ > > > + ethphy0: ethernet-phy@0 { > > > + compatible = "ethernet-phy-ieee802.3-c22"; > > > + reg = <0>; > > > + eee-broken-1000t; > > > + }; > > > > Hi Laurent > > > > Do you happen to know what is broken with respect to EEE? It seems > > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe > > we should be keying off the MAC compatible and disabling this in the > > ethernet driver rather than have every .dts file needing it? > > I wonder if this could be cargo-cult. To be honest, I've copied it from > the BSP and haven't investigated it. I've tried dropping that and > haven't noticed any difference, but I'm not sure how I should test it > properly. Maybe a better approach is to find the errata. It could be some older version of the eqos was broken, and it got fixed along the way? If that is so, moving it into the driver would be better, assuming there is some sort of hardware version register in the eqos. Andrew
(CC'ing Johannes) On Sun, Mar 17, 2024 at 10:55:16PM +0100, Andrew Lunn wrote: > On Sun, Mar 17, 2024 at 08:57:22PM +0200, Laurent Pinchart wrote: > > On Sun, Mar 17, 2024 at 06:17:17PM +0100, Andrew Lunn wrote: > > > > +&eqos { > > > > + pinctrl-names = "default"; > > > > + pinctrl-0 = <&pinctrl_eqos>; > > > > + phy-mode = "rgmii-id"; > > > > + phy-handle = <ðphy0>; > > > > + > > > > + mdio { > > > > + compatible = "snps,dwmac-mdio"; > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + > > > > + /* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */ > > > > + ethphy0: ethernet-phy@0 { > > > > + compatible = "ethernet-phy-ieee802.3-c22"; > > > > + reg = <0>; > > > > + eee-broken-1000t; > > > > + }; > > > > > > Hi Laurent > > > > > > Do you happen to know what is broken with respect to EEE? It seems > > > like a lot of IMX boards have this, so i suspect it is the MAC. Maybe > > > we should be keying off the MAC compatible and disabling this in the > > > ethernet driver rather than have every .dts file needing it? > > > > I wonder if this could be cargo-cult. To be honest, I've copied it from > > the BSP and haven't investigated it. I've tried dropping that and > > haven't noticed any difference, but I'm not sure how I should test it > > properly. > > Maybe a better approach is to find the errata. It could be some older > version of the eqos was broken, and it got fixed along the way? If > that is so, moving it into the driver would be better, assuming there > is some sort of hardware version register in the eqos. I don't know if there are public errata about this issue. It is beyong my areas of expertise. I've found a relatively recent e-mail on the netdev mailing list that seems related ([1]), but there was no reply. [1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/
> I don't know if there are public errata about this issue. It is beyong > my areas of expertise. I've found a relatively recent e-mail on the > netdev mailing list that seems related ([1]), but there was no reply. > > [1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/ Thanks for the link. Has anybody tried setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI. https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c#L816 The problem description makes it sound like the hardware does not like the clock being turned off. Setting this flag might fix that. Andrew
Hi Andrew, On Mon, Mar 18, 2024 at 01:58:56PM +0100, Andrew Lunn wrote: > > I don't know if there are public errata about this issue. It is beyong > > my areas of expertise. I've found a relatively recent e-mail on the > > netdev mailing list that seems related ([1]), but there was no reply. > > > > [1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/ > > Thanks for the link. > > Has anybody tried setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI. > > https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c#L816 > > The problem description makes it sound like the hardware does not like > the clock being turned off. Setting this flag might fix that. How would you recommend proceeding with this patch ? I can drop the eee-broken-1000t property as I didn't notice any issue, or keep with the risk that it my be cargo-cult. This is beyond my area of expertise, so I can perform tests if I get clear instructions, but I don't think I can investigate alone at this point.
On Fri, Jun 07, 2024 at 01:38:23AM +0300, Laurent Pinchart wrote: > Hi Andrew, > > On Mon, Mar 18, 2024 at 01:58:56PM +0100, Andrew Lunn wrote: > > > I don't know if there are public errata about this issue. It is beyong > > > my areas of expertise. I've found a relatively recent e-mail on the > > > netdev mailing list that seems related ([1]), but there was no reply. > > > > > > [1] https://lore.kernel.org/netdev/9c1c9408-88ac-4ade-b8ec-2ae5d8922cac@pengutronix.de/ > > > > Thanks for the link. > > > > Has anybody tried setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI. > > > > https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c#L816 > > > > The problem description makes it sound like the hardware does not like > > the clock being turned off. Setting this flag might fix that. > > How would you recommend proceeding with this patch ? I can drop the > eee-broken-1000t property as I didn't notice any issue, or keep with the > risk that it my be cargo-cult. If you have not noticed any issues, drop it. This thread should hopefully pop up in a search engine if anybody runs into problems. Andrew
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi new file mode 100644 index 000000000000..51964a7059b1 --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi @@ -0,0 +1,309 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright 2021 CompuLab + * Copyright 2024 Ideas on Board Oy + * + * Compulab UCM-iMX8M-Plus System on Module + */ + +#include <dt-bindings/clock/imx8mp-clock.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/irq.h> + +#include "imx8mp-pinfunc.h" +#include "imx8mp.dtsi" + +/ { + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_gpio_led>; + + heartbeat-led { + label = "Heartbeat"; + gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + linux,default-trigger = "heartbeat"; + }; + }; +}; + +&A53_0 { + cpu-supply = <®_arm>; +}; + +&A53_1 { + cpu-supply = <®_arm>; +}; + +&A53_2 { + cpu-supply = <®_arm>; +}; + +&A53_3 { + cpu-supply = <®_arm>; +}; + +&eqos { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_eqos>; + phy-mode = "rgmii-id"; + phy-handle = <ðphy0>; + + mdio { + compatible = "snps,dwmac-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + /* Atheros AR8033 on v1.0, Realtek RTL8211E on v1.1 */ + ethphy0: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + eee-broken-1000t; + }; + }; +}; + +&i2c1 { + clock-frequency = <100000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1>; + status = "okay"; + + pmic@25 { + compatible = "nxp,pca9450c"; + reg = <0x25>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pmic>; + interrupt-parent = <&gpio1>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + + regulators { + BUCK1 { + regulator-name = "BUCK1"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <3125>; + }; + + reg_arm: BUCK2 { + regulator-name = "BUCK2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <3125>; + nxp,dvs-run-voltage = <950000>; + nxp,dvs-standby-voltage = <850000>; + }; + + BUCK4 { + regulator-name = "BUCK4"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + + BUCK5 { + regulator-name = "BUCK5"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + + BUCK6 { + regulator-name = "BUCK6"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + + LDO1 { + regulator-name = "LDO1"; + regulator-min-microvolt = <1600000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + LDO2 { + regulator-name = "LDO2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1150000>; + regulator-boot-on; + regulator-always-on; + }; + + LDO3 { + regulator-name = "LDO3"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + LDO4 { + regulator-name = "LDO4"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + LDO5 { + regulator-name = "LDO5"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; +}; + +&i2c2 { + clock-frequency = <400000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c2>; + status = "okay"; + + eeprom@50 { + compatible = "catalyst,24c08", "atmel,24c08"; + reg = <0x50>; + pagesize = <16>; + }; + + rtc@69 { + compatible = "abracon,ab1805"; + reg = <0x69>; + }; +}; + +&iomuxc { + pinctrl_eqos: eqosgrp { + fsl,pins = < + MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x3 + MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x3 + MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x91 + MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x91 + MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x91 + MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x91 + MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x91 + MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91 + MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x1f + MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x1f + MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x1f + MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x1f + MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x1f + MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x1f + >; + }; + + pinctrl_gpio_led: gpioledgrp { + fsl,pins = < + MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12 0x140 + >; + }; + + pinctrl_i2c1: i2c1grp { + fsl,pins = < + MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c3 + MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3 + >; + }; + + pinctrl_i2c2: i2c2grp { + fsl,pins = < + MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c3 + MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c3 + >; + }; + + pinctrl_pmic: pmicgrp { + fsl,pins = < + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41 + >; + }; + + 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 0xc6 + >; + }; +}; + +&snvs_pwrkey { + status = "okay"; +}; + +/* eMMC */ +&usdhc3 { + assigned-clocks = <&clk IMX8MP_CLK_USDHC3>; + assigned-clock-rates = <400000000>; + pinctrl-names = "default", "state_100mhz", "state_200mhz"; + pinctrl-0 = <&pinctrl_usdhc3>; + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + bus-width = <8>; + non-removable; + status = "okay"; +}; + +&wdog1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_wdog>; + fsl,ext-reset-output; + status = "okay"; +};
The Compulab UCM-iMX8M-Plus is a system on module (SoM) based on an NXP i.MX8MP. It features up to 8GB of LPDDR4, a 64GB eMMC, an ethernet PHY, an RTC and an EEPROM. Add a .dtsi that models the UCM, to be included in board device tree files. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi | 309 ++++++++++++++++++ 1 file changed, 309 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-ucm.dtsi