diff mbox series

[v2,2/5] arm64: dts: freescale: Add device tree for Compulab UCM-iMX8M-Plus

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

Commit Message

Laurent Pinchart March 17, 2024, 4:48 p.m. UTC
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

Comments

Andrew Lunn March 17, 2024, 5:17 p.m. UTC | #1
> +&eqos {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_eqos>;
> +	phy-mode = "rgmii-id";
> +	phy-handle = <&ethphy0>;
> +
> +	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?
Laurent Pinchart March 17, 2024, 6:57 p.m. UTC | #2
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 = <&ethphy0>;
> > +
> > +	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.
Andrew Lunn March 17, 2024, 9:55 p.m. UTC | #3
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 = <&ethphy0>;
> > > +
> > > +	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
Laurent Pinchart March 17, 2024, 11:50 p.m. UTC | #4
(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 = <&ethphy0>;
> > > > +
> > > > +	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/
Andrew Lunn March 18, 2024, 12:58 p.m. UTC | #5
> 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
Laurent Pinchart June 6, 2024, 10:38 p.m. UTC | #6
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.
Andrew Lunn June 10, 2024, 5:16 p.m. UTC | #7
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 mbox series

Patch

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 = <&reg_arm>;
+};
+
+&A53_1 {
+	cpu-supply = <&reg_arm>;
+};
+
+&A53_2 {
+	cpu-supply = <&reg_arm>;
+};
+
+&A53_3 {
+	cpu-supply = <&reg_arm>;
+};
+
+&eqos {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_eqos>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethphy0>;
+
+	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";
+};