arm64: dts: freescale: imx8mm-var-som: Align SOM and Symphony DTSs
Subsystems (2)
cover arm64: dts: freescale: imx8mm-var-som: Align SOM and Symphony DTSs
This series aligns the i.MX8MM VAR-SOM and VAR-SOM Symphony device trees with the latest hardware revisions.
The update consolidates the device tree descriptions to better reflect the actual hardware partitioning between the SOM and the carrier board. Nodes describing peripherals physically present on the SOM are kept in the SOM dtsi, while carrier-specific components are described in the corresponding carrier dts.
The changes were tested on the latest VAR-SOM and Symphony hardware revision.
Stefano Radaelli (11):
arm64: dts: imx8mm-var-som: Move UART4 description to Symphony carrier
arm64: dts: freescale: imx8mm-var-som: Align fsl,pins tables
arm64: dts: freescale: imx8mm-var-som: Update FEC support with
MaxLinear PHY
arm64: dts: imx8mm-var-som: Add support for WM8904 audio codec
arm64: dts: freescale: imx8mm-var-som: Add MCP251xFD CAN controller
arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
arm64: dts: imx8mm-var-som-symphony: Move USB configuration from SOM
arm64: dts: imx8mm-var-som-symphony: Enable uSD on USDHC2
arm64: dts: imx8mm-var-som-symphony: Add TPM2 support
arm64: dts: freescale: imx8mm-var-som-symphony: Enable I2C4
arm64: dts: imx8mm-var-som-symphony: Enable PCIe
.../dts/freescale/imx8mm-var-som-symphony.dts | 206 ++++++++- .../boot/dts/freescale/imx8mm-var-som.dtsi | 420 ++++++++++++------ 2 files changed, 474 insertions(+), 152 deletions(-)
base-commit: 37a93dd5c49b5fda807fd204edf2547c3493319c
Signature · 1 line
2.47.3
PATCH 1/11 arm64: dts: imx8mm-var-som: Move UART4 description to Symphony carrier
From: Stefano Radaelli <[email protected]>
The VAR-SOM-MX8MM module does not provide an onboard debug console. UART4 is routed and exposed only on the Symphony carrier board, while custom carrier designs may choose to expose a different UART.
Move the UART4 node from the SOM device tree to the imx8mm-var-som-symphony.dts, keeping the SOM dtsi limited to hardware present on the module itself.
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 18 ++++++++++++++++++ .../boot/dts/freescale/imx8mm-var-som.dtsi | 18 ------------------ 2 files changed, 18 insertions(+), 18 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +18 -0
@@ -11,6 +11,10 @@ / { model = "Variscite VAR-SOM-MX8MM Symphony evaluation board"; compatible = "variscite,var-som-mx8mm-symphony", "variscite,var-som-mx8mm", "fsl,imx8mm"; + chosen { + stdout-path = &uart4; + }; + reg_usdhc2_vmmc: regulator-usdhc2-vmmc { compatible = "regulator-fixed"; pinctrl-names = "default";
@@ -156,6 +160,13 @@ &uart3 { status = "okay"; }; +/* Console */ +&uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + status = "okay"; +}; + &usbotg1 { disable-over-current; extcon = <&extcon_usbotg1>, <&extcon_usbotg1>;
@@ -251,4 +262,11 @@ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX 0x140 MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX 0x140 >; }; + + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 + >; + }; };
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +0 -18
@@ -9,10 +9,6 @@ / { model = "Variscite VAR-SOM-MX8MM module"; - chosen { - stdout-path = &uart4; - }; - memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0 0x80000000>;
@@ -274,13 +270,6 @@ &uart2 { status = "okay"; }; -/* Console */ -&uart4 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_uart4>; - status = "okay"; -}; - &usbotg1 { dr_mode = "otg"; usb-role-switch;
@@ -418,13 +407,6 @@ MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140 >; }; - pinctrl_uart4: uart4grp { - fsl,pins = < - MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 - MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 - >; - }; - pinctrl_usdhc1: usdhc1grp { fsl,pins = < MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190
Signature · 1 line
2.47.3
PATCH 2/11 arm64: dts: freescale: imx8mm-var-som: Align fsl,pins tables
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Reformat the fsl,pins tables in the i.MX8MM VAR-SOM device tree to use consistent column alignment across all pinctrl groups.
Align the entries to match the formatting already used in the pinctrl_fec1 group, which contains the longest pin definitions, for improved readability and consistency.
No functional changes intended.
--- .../boot/dts/freescale/imx8mm-var-som.dtsi | 170 +++++++++--------- 1 file changed, 85 insertions(+), 85 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +85 -85
@@ -368,171 +368,171 @@ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19 pinctrl_i2c1: i2c1grp { fsl,pins = < - MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3 - MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3 + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3 + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3 >; }; pinctrl_i2c3: i2c3grp { fsl,pins = < - MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3 - MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3 + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3 + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3 >; }; pinctrl_pmic: pmicirqgrp { fsl,pins = < - MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x141 + MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x141 >; }; pinctrl_reg_eth_phy: regethphygrp { fsl,pins = < - MX8MM_IOMUXC_SD1_DATA7_GPIO2_IO9 0x41 + MX8MM_IOMUXC_SD1_DATA7_GPIO2_IO9 0x41 >; }; pinctrl_restouch: restouchgrp { fsl,pins = < - MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c0 + MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c0 >; }; pinctrl_uart2: uart2grp { fsl,pins = < - MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x140 - MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x140 - MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x140 - MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140 + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x140 + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x140 + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x140 + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140 >; }; pinctrl_usdhc1: usdhc1grp { fsl,pins = < - MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190 - MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d0 - MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d0 - MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d0 - MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d0 - MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d0 + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190 + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d0 + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d0 + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d0 + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d0 + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d0 >; }; pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp { fsl,pins = < - MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194 - MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4 - MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d4 - MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d4 - MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d4 - MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d4 + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194 + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4 + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d4 + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d4 + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d4 + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d4 >; }; pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp { fsl,pins = < - MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196 - MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6 - MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d6 - MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d6 - MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d6 - MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d6 + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196 + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6 + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d6 + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d6 + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d6 + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d6 >; }; pinctrl_usdhc2_gpio: usdhc2gpiogrp { fsl,pins = < - MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0xc1 + MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0xc1 >; }; pinctrl_usdhc2: usdhc2grp { fsl,pins = < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190 - MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0 - MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0 - MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 - MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 - MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >; }; pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { fsl,pins = < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194 - MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4 - MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4 - MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 - MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 - MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >; }; pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { fsl,pins = < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196 - MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6 - MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6 - MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 - MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 - MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >; }; pinctrl_usdhc3: usdhc3grp { fsl,pins = < - MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x190 - MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0 - MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0 - MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0 - MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0 - MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0 - MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0 - MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0 - MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0 - MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0 - MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190 + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x190 + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0 + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0 + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0 + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0 + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0 + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0 + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0 + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0 + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0 + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190 >; }; pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { fsl,pins = < - MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194 - MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4 - MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4 - MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4 - MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4 - MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4 - MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4 - MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4 - MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4 - MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4 - MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194 + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194 + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4 + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4 + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4 + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4 + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4 + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4 + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4 + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4 + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4 + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194 >; }; pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { fsl,pins = < - MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196 - MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6 - MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6 - MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6 - MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6 - MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6 - MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6 - MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6 - MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6 - MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6 - MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196 + MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196 + MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6 + MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6 + MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6 + MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6 + MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6 + MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6 + MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6 + MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6 + MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6 + MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196 >; }; pinctrl_wdog: wdoggrp { fsl,pins = < - MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x166 + MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x166 >; }; };
Signature · 1 line
2.47.3
PATCH 3/11 arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.
This patch adds:
- PHY VDDIO 1.8V supply regulator.
- Proper reset timings for the MXL86110.
- LED configuration for link/activity indication via the LED subsystem under /sys/class/leds/, leveraging the support in the MXL86110 PHY driver.
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
- A pinctrl sleep state for low-power operation.
The PHY reset is now handled in the SOM .dtsi using the SoC GPIO. The previous carrier-specific reset-gpios property in the Symphony device tree is therefore removed.
The enet_rst GPIO hog on the carrier is kept to ensure a defined board-level reset line state during boot.
Wake-on-LAN via magic packet is not supported at the VAR-SOM level and is therefore not enabled in the SOM device tree nor in the official evaluation carrier board configuration (symphony).
Designs requiring WoL support may enable it in their own carrier-specific device trees if properly integrated at the hardware level.
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 11 ++-- .../boot/dts/freescale/imx8mm-var-som.dtsi | 59 ++++++++++++++++++- 2 files changed, 63 insertions(+), 7 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +7 -4
@@ -70,10 +70,6 @@ led { }; }; -ðphy { - reset-gpios = <&pca9534 5 GPIO_ACTIVE_HIGH>; -}; - &i2c2 { clock-frequency = <400000>; pinctrl-names = "default";
@@ -99,6 +95,13 @@ usb3-sata-sel-hog { line-name = "usb3_sata_sel"; }; + enet-rst-hog { + gpio-hog; + gpios = <5 GPIO_ACTIVE_HIGH>; + output-low; + line-name = "enet_rst"; + }; + som-vselect-hog { gpio-hog; gpios = <6 GPIO_ACTIVE_HIGH>;
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +56 -3
93 lines not on this page · raw message
Signature · 1 line
2.47.3
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Quoted 4 lines · Stefano Radaelli
From: Stefano Radaelli <[email protected]>
Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.
I don't think you say this explicitly anywhere, so i will ask. The PHY is on the SOM? The carrier just has magnetics and the RJ45?
Quoted 3 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
Andrew
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Hi Andrew!
Quoted 3 lines
I don't think you say this explicitly anywhere, so i will ask. The PHY is on the SOM? The carrier just has magnetics and the RJ45?
Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM. All RGMII signals, MDIO and the LED outputs are routed to the SOM board-to-board connector. The carrier board only provides the magnetics and the RJ45 connector.
Quoted 9 lines
Quoted 4 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier. For this reason, the LED configuration belongs in the SOM .dtsi rather than the carrier .dts.
That said, you are right that describing them as "Yellow" and "Green" ties the description to a specific carrier implementation.
I will drop the color property and keep only the LED function and trigger so that carrier designs can reflect the actual LED implementation if needed.
Does that approach sound acceptable?
As always, thank you for your review.
Best regards,
Stefano
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Quoted 6 lines · Stefano Radaelli
Hi Andrew!
Quoted 3 lines
I don't think you say this explicitly anywhere, so i will ask. The PHY is on the SOM? The carrier just has magnetics and the RJ45?
Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM.
O.K. so far.
Quoted 3 lines
All RGMII signals, MDIO and the LED outputs are routed to the SOM board-to-board connector. The carrier board only provides the magnetics and the RJ45 connector.
And here you loose me. RGMII is between the MAC and the PHY. The PHY is on the SOM, so there is no need for RGMII to leave the SOM.
MDIO is can understand going to the carrier, because there can be other devices on the bus, such as an Ethernet switch.
You say the LEDs are not on the SOM. So they should not be listed in the .dtsi file for the SOM. It could be the RJ45 is a cheap one, without LEDs. The colours will depend on the RJ45 socket. It could be a single LED is connected to the front panel, which is typical of STB etc. So the LEDs are a board property, not a SOM property.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
Quoted 8 lines
Quoted 4 lines
Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier.
The problem here is 'typically', not absolutely required, otherwise the magic smoke will escape making the box useless.
Andrew
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Hi Andrew,
Quoted 22 lines · Andrew Lunn
And here you loose me. RGMII is between the MAC and the PHY. The PHY is on the SOM, so there is no need for RGMII to leave the SOM.
MDIO is can understand going to the carrier, because there can be other devices on the bus, such as an Ethernet switch.
You say the LEDs are not on the SOM. So they should not be listed in the .dtsi file for the SOM. It could be the RJ45 is a cheap one, without LEDs. The colours will depend on the RJ45 socket. It could be a single LED is connected to the front panel, which is typical of STB etc. So the LEDs are a board property, not a SOM property.
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
Quoted 7 lines
Quoted 3 lines
The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier.
The problem here is 'typically', not absolutely required, otherwise the magic smoke will escape making the box useless.
You are right sorry for the confusion: RGMII is internal between the MAC and the PHY and does not leave the SOM. What is exposed on the SOM connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED output signals.
Given that the actual LEDs are implemented on the carrier side (RJ45 with integrated LEDs, pull-ups and LED supply), would you prefer that the LED description is moved out of the SOM .dtsi and into the carrier .dts?
My idea would be to keep the Ethernet controller/PHY node fully described in the SOM .dtsi (since the PHY is on-module), and add only the LED subnode/definition in the carrier .dts where the LEDs are actually present.
If this is the right approach, I will apply the same pattern to the other Variscite SOMs where we currently describe PHY LEDs at the SOM level (e.g. imx8mp-var-som, imx93-var-som).
Thanks again for the review.
Best regards,
Stefano
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Quoted 29 lines · Stefano Radaelli
Hi Andrew,
Quoted 26 lines · Andrew Lunn
And here you loose me. RGMII is between the MAC and the PHY. The PHY is on the SOM, so there is no need for RGMII to leave the SOM.
MDIO is can understand going to the carrier, because there can be other devices on the bus, such as an Ethernet switch.
You say the LEDs are not on the SOM. So they should not be listed in the .dtsi file for the SOM. It could be the RJ45 is a cheap one, without LEDs. The colours will depend on the RJ45 socket. It could be a single LED is connected to the front panel, which is typical of STB etc. So the LEDs are a board property, not a SOM property.
Quoted 12 lines
Quoted 8 lines
Quoted 3 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier.
Quoted 8 lines
Quoted 3 lines
The problem here is 'typically', not absolutely required, otherwise the magic smoke will escape making the box useless.
You are right sorry for the confusion: RGMII is internal between the MAC and the PHY and does not leave the SOM. What is exposed on the SOM connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED output signals.
O.K, that is what i expected.
Quoted 4 lines
Given that the actual LEDs are implemented on the carrier side (RJ45 with integrated LEDs, pull-ups and LED supply), would you prefer that the LED description is moved out of the SOM .dtsi and into the carrier .dts?
Yes please.
Quoted 4 lines
My idea would be to keep the Ethernet controller/PHY node fully described in the SOM .dtsi (since the PHY is on-module), and add only the LED subnode/definition in the carrier .dts where the LEDs are actually present.
Yes. That is good.
Thanks
Andrew
Re: [PATCH v1 03/11] arm64: dts: freescale: imx8mm-var-som: Update FEC support with MaxLinear PHY
Hi Andrew,
Quoted 53 lines · Andrew Lunn
Quoted 29 lines · Stefano Radaelli
Hi Andrew,
Quoted 26 lines · Andrew Lunn
And here you loose me. RGMII is between the MAC and the PHY. The PHY is on the SOM, so there is no need for RGMII to leave the SOM.
MDIO is can understand going to the carrier, because there can be other devices on the bus, such as an Ethernet switch.
You say the LEDs are not on the SOM. So they should not be listed in the .dtsi file for the SOM. It could be the RJ45 is a cheap one, without LEDs. The colours will depend on the RJ45 socket. It could be a single LED is connected to the front panel, which is typical of STB etc. So the LEDs are a board property, not a SOM property.
Quoted 12 lines
Quoted 8 lines
Quoted 3 lines
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier.
The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier.
Quoted 8 lines
Quoted 3 lines
The problem here is 'typically', not absolutely required, otherwise the magic smoke will escape making the box useless.
You are right sorry for the confusion: RGMII is internal between the MAC and the PHY and does not leave the SOM. What is exposed on the SOM connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED output signals.
O.K, that is what i expected.
Quoted 4 lines
Given that the actual LEDs are implemented on the carrier side (RJ45 with integrated LEDs, pull-ups and LED supply), would you prefer that the LED description is moved out of the SOM .dtsi and into the carrier .dts?
Yes please.
Quoted 4 lines
My idea would be to keep the Ethernet controller/PHY node fully described in the SOM .dtsi (since the PHY is on-module), and add only the LED subnode/definition in the carrier .dts where the LEDs are actually present.
Quoted 4 lines
Yes. That is good.
Thanks
Andrew
I will send the v2 with led descriptions in Symphony dts instead of SOM dtsi.
Thank you again,
Best Regards,
Stefano
PATCH 4/11 arm64: dts: imx8mm-var-som: Add support for WM8904 audio codec
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
The VAR-SOM-MX8MM can integrate the WM8904, a high-performance ultra-low-power stereo codec optimized for portable audio applications.
This patch adds the WM8904 device to the appropriate I2C bus, enables the SAI peripheral, and introduces the sound node to expose the sound card to the system.
--- .../boot/dts/freescale/imx8mm-var-som.dtsi | 101 +++++++++++++++++- 1 file changed, 98 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +98 -3
@@ -15,6 +15,14 @@ memory@40000000 { reg = <0x0 0x40000000 0 0x80000000>; }; + reg_audio_supply: regulator-3p3v { + compatible = "regulator-fixed"; + regulator-name = "wm8904-supply"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + reg_eth_phy: regulator-eth-phy { compatible = "regulator-fixed"; pinctrl-names = "default";
@@ -32,6 +40,34 @@ reg_phy_vddio: regulator-phy-vddio { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; + + sound { + compatible = "simple-audio-card"; + simple-audio-card,bitclock-master = <&codec_dai>; + simple-audio-card,format = "i2s"; + simple-audio-card,frame-master = <&codec_dai>; + simple-audio-card,mclk-fs = <256>; + simple-audio-card,name = "wm8904-audio"; + simple-audio-card,routing = + "Headphone Jack", "HPOUTL", + "Headphone Jack", "HPOUTR", + "IN2L", "Line In Jack", + "IN2R", "Line In Jack", + "IN1L", "Microphone Jack", + "IN1R", "Microphone Jack"; + simple-audio-card,widgets = + "Microphone", "Microphone Jack", + "Headphone", "Headphone Jack", + "Line", "Line In Jack"; + + codec_dai: simple-audio-card,codec { + sound-dai = <&wm8904>; + }; + + simple-audio-card,cpu { + sound-dai = <&sai5>; + }; + }; }; &A53_0 {
@@ -277,18 +313,58 @@ ldo6_reg: LDO6 { &i2c3 { clock-frequency = <400000>; - pinctrl-names = "default"; + pinctrl-names = "default", "gpio"; pinctrl-0 = <&pinctrl_i2c3>; + pinctrl-1 = <&pinctrl_i2c3_gpio>; + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; status = "okay"; - /* TODO: configure audio, as of now just put a placeholder */ wm8904: codec@1a { compatible = "wlf,wm8904"; reg = <0x1a>; - status = "disabled"; + #sound-dai-cells = <0>; + clocks = <&clk IMX8MM_CLK_SAI5_ROOT>; + clock-names = "mclk"; + AVDD-supply = <&ldo5_reg>; + CPVDD-supply = <&ldo5_reg>; + DBVDD-supply = <®_audio_supply>; + DCVDD-supply = <&ldo5_reg>; + MICVDD-supply = <&ldo5_reg>; + wlf,drc-cfg-names = "default", "peaklimiter", "tradition", + "soft", "music"; + /* + * Config registers per name, respectively: + * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1 + * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 + * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 + * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 + * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 + */ + wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>, + /bits/ 16 <0x04af 0x324b 0x0010 0x0408>, + /bits/ 16 <0x04af 0x324b 0x0028 0x0704>, + /bits/ 16 <0x04af 0x324b 0x0018 0x078c>, + /bits/ 16 <0x04af 0x324b 0x0010 0x050e>; + /* GPIO1 = DMIC_CLK, don't touch others */ + wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>; + status = "okay"; }; }; +&sai5 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_sai5>; + assigned-clocks = <&clk IMX8MM_CLK_SAI5>; + assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>; + assigned-clock-rates = <1536000>; + #sound-dai-cells = <0>; + dmas = <&sdma2 8 25 0>, <&sdma2 9 25 0>; + dma-names = "rx", "tx"; + fsl,sai-mclk-direction-output; + status = "okay"; +}; + &snvs_pwrkey { status = "okay"; };
@@ -433,6 +509,13 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3 >; }; + pinctrl_i2c3_gpio: i2c3gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 0x1c3 + MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 0x1c3 + >; + }; + pinctrl_pmic: pmicirqgrp { fsl,pins = < MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x141
@@ -451,6 +534,18 @@ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c0 >; }; + pinctrl_sai5: sai5grp { + fsl,pins = < + MX8MM_IOMUXC_SAI5_RXD1_SAI5_TX_SYNC 0xd6 + MX8MM_IOMUXC_SAI5_RXFS_SAI5_RX_SYNC 0xd6 + MX8MM_IOMUXC_SAI5_RXD3_SAI5_TX_DATA0 0xd6 + MX8MM_IOMUXC_SAI5_RXD0_SAI5_RX_DATA0 0xd6 + MX8MM_IOMUXC_SAI5_RXC_SAI5_RX_BCLK 0xd6 + MX8MM_IOMUXC_SAI5_RXD2_SAI5_TX_BCLK 0xd6 + MX8MM_IOMUXC_SAI5_MCLK_SAI5_MCLK 0xd6 + >; + }; + pinctrl_uart2: uart2grp { fsl,pins = < MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x140
Signature · 1 line
2.47.3
PATCH 5/11 arm64: dts: freescale: imx8mm-var-som: Add MCP251xFD CAN controller
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Add support for the Microchip MCP251xFD CAN-FD controller connected to the SPI bus on the i.MX8MM VAR-SOM.
The controller uses a 40 MHz external oscillator and requires an interrupt line and a dedicated RX interrupt GPIO.
This patch adds the fixed clock, the MCP251xFD device node with the required properties, and the corresponding pinctrl configuration.
--- .../boot/dts/freescale/imx8mm-var-som.dtsi | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+)
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +27 -0
@@ -15,6 +15,13 @@ memory@40000000 { reg = <0x0 0x40000000 0 0x80000000>; }; + clk40m: oscillator { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <40000000>; + clock-output-names = "can_osc"; + }; + reg_audio_supply: regulator-3p3v { compatible = "regulator-fixed"; regulator-name = "wm8904-supply";
@@ -140,6 +147,19 @@ touchscreen@0 { ti,keep-vref-on; wakeup-source; }; + + /* CAN controller */ + can0: can@1 { + compatible = "microchip,mcp251xfd"; + reg = <1>; + clocks = <&clk40m>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_can>; + interrupt-parent = <&gpio1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + microchip,rx-int-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>; + spi-max-frequency = <20000000>; + }; }; &fec1 {
@@ -445,6 +465,13 @@ &wdog1 { }; &iomuxc { + pinctrl_can: cangrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x16 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x16 + >; + }; + pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x13
Signature · 1 line
2.47.3
PATCH 6/11 arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM to match the latest SOM hardware revision.
The SOM now integrates an NXP IW61x wireless module. WiFi is connected via SDIO and Bluetooth via UART.
This patch:
- Adds an mmc-pwrseq node to handle module reset and power sequencing.
- Updates the USDHC1 node to use the new power sequence and required pinctrl configuration.
- Adds the Bluetooth child node under UART2.
- Removes the legacy Broadcom WiFi device node.
--- .../boot/dts/freescale/imx8mm-var-som.dtsi | 41 ++++++++++++++----- 1 file changed, 30 insertions(+), 11 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +30 -11
@@ -22,6 +22,14 @@ clk40m: oscillator { clock-output-names = "can_osc"; }; + iw61x_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + post-power-on-delay-ms = <100>; + power-off-delay-us = <10000>; + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */ + <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */ + }; + reg_audio_supply: regulator-3p3v { compatible = "regulator-fixed"; regulator-name = "wm8904-supply";
@@ -392,11 +400,15 @@ &snvs_pwrkey { /* Bluetooth */ &uart2 { pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_uart2>; + pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_bt>; assigned-clocks = <&clk IMX8MM_CLK_UART2>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; uart-has-rtscts; status = "okay"; + + bluetooth_iw61x: bluetooth { + compatible = "nxp,88w8987-bt"; + }; }; &usbotg1 {
@@ -413,21 +425,15 @@ &usbotg2 { /* WIFI */ &usdhc1 { - #address-cells = <1>; - #size-cells = <0>; pinctrl-names = "default", "state_100mhz", "state_200mhz"; - pinctrl-0 = <&pinctrl_usdhc1>; - pinctrl-1 = <&pinctrl_usdhc1_100mhz>; - pinctrl-2 = <&pinctrl_usdhc1_200mhz>; + pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>; + pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>; + pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>; bus-width = <4>; non-removable; keep-power-in-suspend; + mmc-pwrseq = <&iw61x_pwrseq>; status = "okay"; - - brcmf: wifi@1 { - reg = <1>; - compatible = "brcm,bcm4329-fmac"; - }; }; /* SD */
@@ -465,6 +471,12 @@ &wdog1 { }; &iomuxc { + pinctrl_bt: bluetoothgrp { + fsl,pins = < + MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1 + >; + }; + pinctrl_can: cangrp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x16
@@ -710,4 +722,11 @@ pinctrl_wdog: wdoggrp { MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x166 >; }; + + pinctrl_wifi: wifigrp { + fsl,pins = < + MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 0x140 + MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10 0xc1 + >; + }; };
Signature · 1 line
2.47.3
Fabio Estevam
reviewerRe: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Hi Stefano,
Quoted 9 lines · Stefano Radaelli
From: Stefano Radaelli <[email protected]>
Update the WiFi and Bluetooth configuration on the i.MX8MM VAR-SOM to match the latest SOM hardware revision.
The SOM now integrates an NXP IW61x wireless module. WiFi is connected via SDIO and Bluetooth via UART.
Quoted 6 lines
This patch:
- Adds an mmc-pwrseq node to handle module reset and power sequencing.
- Updates the USDHC1 node to use the new power sequence and required pinctrl configuration.
- Adds the Bluetooth child node under UART2.
- Removes the legacy Broadcom WiFi device node.
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Hi Fabio!
Quoted 4 lines · Fabio Estevam
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
Since the wireless module is soldered on the SOM and not selectable via the carrier board, the device tree must reflect the hardware that is actually present on the module. This series aligns mainline with the current production revision of the SOM.
Customers using older hardware revisions still have access to the corresponding device tree descriptions in earlier kernel versions. Upstream support is being aligned with the actively produced hardware.
The same applies to the Ethernet PHY update included in this series, which reflects the PHY used on the current (and future) SOM revision.
Best regards,
Stefano
Frank Li
maintainerRe: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Quoted 4 lines · Stefano Radaelli
Hi Fabio!
Quoted 1 line · Fabio Estevam
Quoted 8 lines
Quoted 3 lines
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
This common problem, we met similar case. After replace new compenent, it should be new boards, or new revision.
I don't suggest directly replace it to broken old one. You can create dt overlay files for new boards.
Krzysztof Kozlowski:
how about other vendor handle similar case? Any guide line for
that?
Frank
Quoted 15 lines
Since the wireless module is soldered on the SOM and not selectable via the carrier board, the device tree must reflect the hardware that is actually present on the module. This series aligns mainline with the current production revision of the SOM.
Customers using older hardware revisions still have access to the corresponding device tree descriptions in earlier kernel versions. Upstream support is being aligned with the actively produced hardware.
The same applies to the Ethernet PHY update included in this series, which reflects the PHY used on the current (and future) SOM revision.
Best regards,
Stefano
Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Hi Frank,
Quoted 17 lines · Frank Li
Quoted 4 lines · Stefano Radaelli
Hi Fabio!
Quoted 1 line · Fabio Estevam
Quoted 8 lines
Quoted 3 lines
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
This common problem, we met similar case. After replace new compenent, it should be new boards, or new revision.
Quoted 9 lines
I don't suggest directly replace it to broken old one. You can create dt overlay files for new boards.
Krzysztof Kozlowski:
how about other vendor handle similar case? Any guide line for
that?Frank
Thanks for the feedback!
We understand the concern about potential regressions on older SOM revisions. However, since the wireless module is soldered on the SOM and not configurable, we are aligning the upstream device tree with the hardware revision that is currently in production.
This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM platforms already present in mainline (e.g. i.MX8MP, i.MX93), which use the IW61x wireless module as well. The intention is to keep the VAR-SOM family consistent in mainline with the hardware that is actively produced.
If there is a strong requirement to preserve an explicit description of the older Broadcom-based revision in mainline, we can evaluate adding a separate description.
Best regards,
Stefano
Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Hello everyone,
Quoted 43 lines · Stefano Radaelli
Hi Frank,
Quoted 17 lines · Frank Li
Quoted 4 lines · Stefano Radaelli
Hi Fabio!
Quoted 1 line · Fabio Estevam
Quoted 8 lines
Quoted 3 lines
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
This common problem, we met similar case. After replace new compenent, it should be new boards, or new revision.
Quoted 9 lines
I don't suggest directly replace it to broken old one. You can create dt overlay files for new boards.
Krzysztof Kozlowski:
how about other vendor handle similar case? Any guide line for
that?Frank
Thanks for the feedback!
We understand the concern about potential regressions on older SOM revisions. However, since the wireless module is soldered on the SOM and not configurable, we are aligning the upstream device tree with the hardware revision that is currently in production.
This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM platforms already present in mainline (e.g. i.MX8MP, i.MX93), which use the IW61x wireless module as well. The intention is to keep the VAR-SOM family consistent in mainline with the hardware that is actively produced.
Quoted 6 lines
If there is a strong requirement to preserve an explicit description of the older Broadcom-based revision in mainline, we can evaluate adding a separate description.
Best regards,
Stefano
Do you have any update about this topic?
Thank you a lot,
Best Regards,
Stefano
Frank Li
maintainerRe: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Quoted 45 lines · Stefano Radaelli
Hello everyone,
Quoted 42 lines · Stefano Radaelli
Hi Frank,
Quoted 17 lines · Frank Li
Quoted 4 lines · Stefano Radaelli
Hi Fabio!
Quoted 1 line · Fabio Estevam
Quoted 8 lines
Quoted 3 lines
What about users who still have boards with the Broadcom Wi-Fi chip?
Will Wifi on the old boards stop working?
The Broadcom-based WiFi module was used on earlier revisions of the VAR-SOM-MX8MM. That hardware revision is no longer in production and is not available for new orders. All currently manufactured and shipped VAR-SOM-MX8MM modules integrate the NXP IW61x instead.
This common problem, we met similar case. After replace new compenent, it should be new boards, or new revision.
Quoted 9 lines
I don't suggest directly replace it to broken old one. You can create dt overlay files for new boards.
Krzysztof Kozlowski:
how about other vendor handle similar case? Any guide line for
that?Frank
Thanks for the feedback!
We understand the concern about potential regressions on older SOM revisions. However, since the wireless module is soldered on the SOM and not configurable, we are aligning the upstream device tree with the hardware revision that is currently in production.
This change also aligns the i.MX8MM VAR-SOM with other VAR-SOM platforms already present in mainline (e.g. i.MX8MP, i.MX93), which use the IW61x wireless module as well. The intention is to keep the VAR-SOM family consistent in mainline with the hardware that is actively produced.
Actually it becomes two boards. Change components is quite common. Direct change at dts is not friendly for old boards users.
Quoted 9 lines
Quoted 7 lines
If there is a strong requirement to preserve an explicit description of the older Broadcom-based revision in mainline, we can evaluate adding a separate description.
Best regards,
StefanoDo you have any update about this topic?
If can't auto detected, I think keep old dts, use overlay change to new one.
For example, board.dtb
you can rename board.dtb to board-revA.dtb
new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use board-revb.dtb.
If change is big, you can create new one.
Frank
Quoted 4 lines
Thank you a lot,
Best Regards,
Stefano
Re: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Hi Frank,
Quoted 6 lines · Frank Li
If can't auto detected, I think keep old dts, use overlay change to new one.
For example, board.dtb
Quoted 7 lines
you can rename board.dtb to board-revA.dtb
new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use board-revb.dtb.If change is big, you can create new one.
Frank
Thanks for the clarification, I understand that the preferred approach would be to keep the existing Broadcom-based DTS unchanged and add a separate description for the IW612-based revision.
My only concern is avoiding confusion in mainline.
The Broadcom-based SOM revision is obsolete and no longer manufactured. All currently produced VAR-SOM-MX8MM modules use the IW612 module, and this will remain the only production hardware going forward.
I would like to avoid giving the impression that we are actively supporting two parallel SOM revisions in mainline, while in reality only the IW612-based hardware exists in production.
For this reason, would it be acceptable to:
- move the Broadcom-based description into an explicitly legacy revision-specific DTS (kept unchanged for existing users), and
- update the main imx8mm-var-som DTS to reflect the current IW612-based hardware?
This would preserve compatibility for older boards, but ensure that the primary DTS in mainline represents the hardware that is actually produced and aligns with the rest of the VAR-SOM family.
Thank you again for your support and your patience!
Best regards,
Stefano
Frank Li
maintainerRe: [PATCH v1 06/11] arm64: dts: freescale: imx8mm-var-som: Update WiFi/BT configuration
Quoted 31 lines · Stefano Radaelli
Hi Frank,
Quoted 6 lines · Frank Li
If can't auto detected, I think keep old dts, use overlay change to new one.
For example, board.dtb
Quoted 7 lines
you can rename board.dtb to board-revA.dtb
new board.dtb, by apply verb.dtso to board-revA.dtb. Or you direct use board-revb.dtb.If change is big, you can create new one.
Frank
Thanks for the clarification, I understand that the preferred approach would be to keep the existing Broadcom-based DTS unchanged and add a separate description for the IW612-based revision.
My only concern is avoiding confusion in mainline.
The Broadcom-based SOM revision is obsolete and no longer manufactured. All currently produced VAR-SOM-MX8MM modules use the IW612 module, and this will remain the only production hardware going forward.
I would like to avoid giving the impression that we are actively supporting two parallel SOM revisions in mainline, while in reality only the IW612-based hardware exists in production.
Quoted 6 lines
For this reason, would it be acceptable to:
- move the Broadcom-based description into an explicitly legacy revision-specific DTS (kept unchanged for existing users), and
- update the main imx8mm-var-som DTS to reflect the current IW612-based hardware?
The direction is correct. Just try to reduce duplicate the same code.
Frank
Quoted 9 lines
This would preserve compatibility for older boards, but ensure that the primary DTS in mainline represents the hardware that is actually produced and aligns with the rest of the VAR-SOM family.
Thank you again for your support and your patience!
Best regards,
Stefano
PATCH 7/11 arm64: dts: imx8mm-var-som-symphony: Move USB configuration from SOM
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Move the USB controller configuration out of the i.MX8MM VAR-SOM dtsi and into the VAR-SOM Symphony carrier board dts.
The SOM does not provide any USB connectors and carrier boards may choose whether and how to route USB, therefore USB should be described in the carrier-specific device tree instead of the SOM include.
While moving the nodes, align the Symphony USB description with the carrier design by enabling both USB controllers, wiring USB1 to the PTN5150 Type-C controller for dual-role operation, and updating the PHY tuning and VBUS regulator pinctrl (including a sleep state).
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 52 ++++++++++++------- .../boot/dts/freescale/imx8mm-var-som.dtsi | 12 ----- 2 files changed, 34 insertions(+), 30 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +34 -18
@@ -30,6 +30,7 @@ reg_usb_otg2_vbus: regulator-usb-otg2-vbus { compatible = "regulator-fixed"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_reg_usb_otg2_vbus>; + pinctrl-1 = <&pinctrl_reg_usb_otg2_vbus_sleep>; regulator-name = "usb_otg2_vbus"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>;
@@ -117,13 +118,20 @@ enet-sel-hog { }; }; - extcon_usbotg1: typec@3d { + /* USB Type-C Controller */ + ptn5150: typec@3d { compatible = "nxp,ptn5150"; reg = <0x3d>; - interrupt-parent = <&gpio1>; - interrupts = <11 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ptn5150>; + interrupt-parent = <&gpio1>; + interrupts = <11 IRQ_TYPE_NONE>; + + port { + typec1_dr_sw: endpoint { + remote-endpoint = <&usb1_drd_sw>; + }; + }; }; };
@@ -171,27 +179,29 @@ &uart4 { }; &usbotg1 { - disable-over-current; - extcon = <&extcon_usbotg1>, <&extcon_usbotg1>; + dr_mode = "otg"; + hnp-disable; + srp-disable; + adp-disable; + usb-role-switch; + samsung,picophy-pre-emp-curr-control = <3>; + samsung,picophy-dc-vol-level-adjust = <7>; + status = "okay"; + + port { + usb1_drd_sw: endpoint { + remote-endpoint = <&typec1_dr_sw>; + }; + }; }; &usbotg2 { dr_mode = "host"; vbus-supply = <®_usb_otg2_vbus>; - srp-disable; - hnp-disable; - adp-disable; + samsung,picophy-pre-emp-curr-control = <3>; + samsung,picophy-dc-vol-level-adjust = <7>; disable-over-current; - /delete-property/ usb-role-switch; - /* - * FIXME: having USB2 enabled hangs the boot just after: - * [ 1.943365] ci_hdrc ci_hdrc.1: EHCI Host Controller - * [ 1.948287] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1 - * [ 1.971006] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00 - * [ 1.977203] hub 1-0:1.0: USB hub found - * [ 1.980987] hub 1-0:1.0: 1 port detected - */ - status = "disabled"; + status = "okay"; }; &pinctrl_fec1 {
@@ -246,6 +256,12 @@ MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1 0x16 >; }; + pinctrl_reg_usb_otg2_vbus_sleep: regusbotg2vbus-sleepgrp { + fsl,pins = < + MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1 0x120 + >; + }; + pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { fsl,pins = < MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi +0 -12
@@ -411,18 +411,6 @@ bluetooth_iw61x: bluetooth { }; }; -&usbotg1 { - dr_mode = "otg"; - usb-role-switch; - status = "okay"; -}; - -&usbotg2 { - dr_mode = "otg"; - usb-role-switch; - status = "okay"; -}; - /* WIFI */ &usdhc1 { pinctrl-names = "default", "state_100mhz", "state_200mhz";
Signature · 1 line
2.47.3
PATCH 8/11 arm64: dts: imx8mm-var-som-symphony: Enable uSD on USDHC2
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Enable the microSD slot on the VAR-SOM Symphony carrier board.
Configure USDHC2 with card-detect GPIO, pinctrl states for the supported bus speeds and the required VMMC supply.
Update the VMMC regulator to match the latest carrier revision by moving the enable GPIO to GPIO4_IO22 and adding the required off-on delay.
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 59 ++++++++++++++++++- 1 file changed, 57 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +57 -2
@@ -22,7 +22,8 @@ reg_usdhc2_vmmc: regulator-usdhc2-vmmc { regulator-name = "VSD_3V3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; - gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>; + gpio = <&gpio4 22 GPIO_ACTIVE_HIGH>; + off-on-delay-us = <20000>; enable-active-high; };
@@ -204,6 +205,18 @@ &usbotg2 { status = "okay"; }; +/* SD */ +&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>; + cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; + vmmc-supply = <®_usdhc2_vmmc>; + bus-width = <4>; + status = "okay"; +}; + &pinctrl_fec1 { fsl,pins = < MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
@@ -264,7 +277,7 @@ MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1 0x120 pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { fsl,pins = < - MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41 + MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 0x41 >; };
@@ -288,4 +301,46 @@ MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 >; }; + + pinctrl_usdhc2: usdhc2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + >; + }; + + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + >; + }; + + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196 + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6 + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6 + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + >; + }; + + pinctrl_usdhc2_gpio: usdhc2gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0xc1 + >; + }; };
Signature · 1 line
2.47.3
PATCH 9/11 arm64: dts: imx8mm-var-som-symphony: Add TPM2 support
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Add support for the TPM2 device on the VAR-SOM Symphony carrier board.
The ST33K TPM2 is connected over I2C, and A PCA6408 GPIO expander is used to control the reset signal required to release the TPM from reset.
This patch adds:
- The PCA6408 GPIO expander.
- The ST33K TPM2 device node.
--- .../boot/dts/freescale/imx8mm-var-som-symphony.dts | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +14 -0
@@ -137,6 +137,20 @@ typec1_dr_sw: endpoint { }; &i2c3 { + pca6408: gpio@21 { + compatible = "nxp,pcal6408"; + reg = <0x21>; + gpio-controller; + #gpio-cells = <2>; + }; + + st33ktpm2xi2c: tpm@2e { + compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c"; + reg = <0x2e>; + label = "tpm"; + reset-gpios = <&pca6408 4 GPIO_ACTIVE_LOW>; + }; + /* Capacitive touch controller */ ft5x06_ts: touchscreen@38 { compatible = "edt,edt-ft5406";
Signature · 1 line
2.47.3
PATCH 10/11 arm64: dts: freescale: imx8mm-var-som-symphony: Enable I2C4
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Enable I2C4 on the Symphony carrier and add pinctrl configuration, including GPIO-based bus recovery support.
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +24 -0
@@ -172,6 +172,16 @@ rtc@68 { }; }; +&i2c4 { + clock-frequency = <100000>; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c4>; + pinctrl-1 = <&pinctrl_i2c4_gpio>; + scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; +}; + /* Header */ &uart1 { pinctrl-names = "default";
@@ -265,6 +275,20 @@ MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA 0x400001c3 >; }; + pinctrl_i2c4: i2c4grp { + fsl,pins = < + MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x400001c3 + MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x400001c3 + >; + }; + + pinctrl_i2c4_gpio: i2c4gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C4_SCL_GPIO5_IO20 0x1c3 + MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21 0x1c3 + >; + }; + pinctrl_pca9534: pca9534grp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x16
Signature · 1 line
2.47.3
PATCH 11/11 arm64: dts: imx8mm-var-som-symphony: Enable PCIe
In reply to Stefano RadaelliFrom: Stefano Radaelli <[email protected]>
Enable PCIe support on the VAR-SOM Symphony carrier board by adding the external reference clock, configuring the PHY and providing the required clock and reset properties.
--- .../dts/freescale/imx8mm-var-som-symphony.dts | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+)
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts +28 -0
@@ -5,6 +5,7 @@ /dts-v1/; +#include <dt-bindings/phy/phy-imx8-pcie.h> #include "imx8mm-var-som.dtsi" / {
@@ -15,6 +16,12 @@ chosen { stdout-path = &uart4; }; + pcie0_refclk: pcie0-refclk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + }; + reg_usdhc2_vmmc: regulator-usdhc2-vmmc { compatible = "regulator-fixed"; pinctrl-names = "default";
@@ -182,6 +189,27 @@ &i2c4 { status = "okay"; }; +&pcie_phy { + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>; + fsl,tx-deemph-gen1 = <0x2d>; + fsl,tx-deemph-gen2 = <0xf>; + fsl,clkreq-unsupported; + clocks = <&pcie0_refclk>; + status = "okay"; +}; + +&pcie0 { + reset-gpio = <&pca6408 1 GPIO_ACTIVE_LOW>; + clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&pcie0_refclk>, + <&clk IMX8MM_CLK_PCIE1_AUX>; + assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>, + <&clk IMX8MM_CLK_PCIE1_CTRL>; + assigned-clock-rates = <10000000>, <250000000>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>, + <&clk IMX8MM_SYS_PLL2_250M>; + status = "okay"; +}; + /* Header */ &uart1 { pinctrl-names = "default";
Signature · 1 line
2.47.3