Skip to contentSkip to conversation

Add support for Variscite VAR-SOM-MX8QM and Symphony board

PATCH Superseded Stefano Radaelli 3 participants 7 messages Jul 15

Subsystems (2)
Device tree bindings Arm i.MX and Layerscape

v3 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

Stefano Radaelli

author
#0 lore raw

v3 cover Add support for Variscite VAR-SOM-MX8QM and Symphony board

This patch series adds support for the Variscite VAR-SOM-MX8 QuadMax system on module and the Symphony carrier board.

The series includes:
- SOM device tree with on-module peripherals
- Symphony carrier board device tree with board-specific features

The implementation follows the standard SOM + carrier board pattern where the SOM dtsi contains only peripherals mounted on the module, while carrier-specific interfaces are enabled in the board dts.

v2->v3:
- Fix led typo
- Moved reset-gpios in pciea_port0
- Removed wrong captouch pinctrl gpio

v1->v2:
- Added non-removable property to usdhc3
- Removed unused fec gpio pinctrl
- Fix ptn5150 interrupt
- Fix ecspi1 cs gpio

Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax
arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx8qm-var-som-symphony.dts | 490 ++++++++++++++++
 .../boot/dts/freescale/imx8qm-var-som.dtsi    | 530 ++++++++++++++++++
 4 files changed, 1027 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi

base-commit: d0c222c2e2ce577d801bdf129dc6c078f29e22df
prerequisite-patch-id: 0996915f031a1d899202c5fba75a969d6ce2a53d
prerequisite-patch-id: dbed47ecb907f6b7f7e284c5c1a3c325566eafd7
prerequisite-patch-id: c758aa296e6effc94c30449cc7e4773f0ae02914
prerequisite-patch-id: 31784fa7a3ee5c178b2f1ffa97c1dd7c1d3d898a
prerequisite-patch-id: 5810f43cde9c24ee318d680c1852b3ded18f3aa0
prerequisite-patch-id: 012c9c8ba4e290532a1b7f8642274b7c5f252e03
prerequisite-patch-id: a57d576be42d5061bba453f0d5960132be55a1ff
prerequisite-patch-id: e34a75fb6f7e01455dd5ca734dacad66b12de06c
prerequisite-patch-id: cc7abadd0354d14bad0cac1fbacda14ab9d4e02b
prerequisite-patch-id: c0276686c0247cb2385c56b96cbfd6de5128415c
prerequisite-patch-id: 100c47538870af63194b407fae06183fee85fc09
prerequisite-patch-id: 3a3b3e40f5fba785857091dda909d22bfc5e2d0e

Signature · 1 line
2.47.3
author
#1 lore raw

PATCH v3 1/3 dt-bindings: arm: fsl: add Variscite VAR-SOM-MX8 QuadMax Boards

From: Stefano Radaelli <[email protected]>

Add DT compatible strings for Variscite VAR-SOM-MX8 QuadMax SoM and Variscite Symphony development carrier Board.

Acked-by Krzysztof Kozlowski <[email protected]>
Signed-off-by Stefano Radaelli <[email protected]>

---
v2->v3:
-

v1->v2:
-

 Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/arm/fsl.yaml +6 -0
index 6237fb2ae50e..532e4308dc46 100644
@@ -1381,6 +1381,12 @@ properties:
               - fsl,imx8qm-mek-revd      # i.MX8QM MEK Rev D Board
           - const: fsl,imx8qm
 
+      - description: i.MX8QM Variscite VAR-SOM-MX8 based Boards
+        items:
+          - const: variscite,var-som-imx8qm-symphony
+          - const: variscite,var-som-imx8qm
+          - const: fsl,imx8qm
+
       - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules
         items:
           - enum:
Signature · 1 line
2.47.3
author
#2 lore raw

PATCH v3 2/3 arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

In reply to Stefano Radaelli

From: Stefano Radaelli <[email protected]>

Add device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module.
This SOM is designed to be used with various carrier boards.

The module includes:
- NXP i.MX8 QuadMax MPU processor
- Up to 8GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth

Only SOM-specific peripherals are enabled by default. Carrier board specific interfaces are left disabled to be enabled in the respective carrier board device trees.

Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
Signed-off-by Stefano Radaelli <[email protected]>

---
v2->v3:
-

v1->v2:
- Added non-removable property to usdhc3
- Removed unused fec gpio pinctrl

 .../boot/dts/freescale/imx8qm-var-som.dtsi    | 530 ++++++++++++++++++
 1 file changed, 530 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +530 -0
new file mode 100644
index 000000000000..08b02173b780
@@ -0,0 +1,530 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite VAR-SOM-MX8
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx8qm.dtsi"
+
+/ {
+	model = "Variscite i.MX8QM VAR-SOM-MX8 Module";
+	compatible = "variscite,var-som-imx8qm", "fsl,imx8qm";
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x40000000>;
+	};
+
+	reg_audio_supply: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "wm8904-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_phy_vddio: regulator-phy-vddio {
+		compatible = "regulator-fixed";
+		regulator-name = "vddio-1v8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		vdev0vring0: memory@90000000 {
+			reg = <0 0x90000000 0 0x8000>;
+			no-map;
+		};
+
+		vdev0vring1: memory@90008000 {
+			reg = <0 0x90008000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring0: memory@90010000 {
+			reg = <0 0x90010000 0 0x8000>;
+			no-map;
+		};
+
+		vdev1vring1: memory@90018000 {
+			reg = <0 0x90018000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table0: memory@900ff000 {
+			reg = <0 0x900ff000 0 0x1000>;
+			no-map;
+		};
+
+		vdev2vring0: memory@90100000 {
+			reg = <0 0x90100000 0 0x8000>;
+			no-map;
+		};
+
+		vdev2vring1: memory@90108000 {
+			reg = <0 0x90108000 0 0x8000>;
+			no-map;
+		};
+
+		vdev3vring0: memory@90110000 {
+			reg = <0 0x90110000 0 0x8000>;
+			no-map;
+		};
+
+		vdev3vring1: memory@90118000 {
+			reg = <0 0x90118000 0 0x8000>;
+			no-map;
+		};
+
+		rsc_table1: memory@901ff000 {
+			reg = <0 0x901ff000 0 0x1000>;
+			no-map;
+		};
+
+		vdevbuffer: memory@90400000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x90400000 0 0x100000>;
+			no-map;
+		};
+
+		dsp_reserved: memory@92400000 {
+			reg = <0 0x92400000 0 0x1000000>;
+			no-map;
+		};
+
+		dsp_vdev0vring0: memory@942f0000 {
+			reg = <0 0x942f0000 0 0x8000>;
+			no-map;
+		};
+
+		dsp_vdev0vring1: memory@942f8000 {
+			reg = <0 0x942f8000 0 0x8000>;
+			no-map;
+		};
+
+		dsp_vdev0buffer: memory@94300000 {
+			compatible = "shared-dma-pool";
+			reg = <0 0x94300000 0 0x100000>;
+			no-map;
+		};
+
+		/* global autoconfigured region for contiguous allocations */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0 0xc0000000 0 0x3c000000>;
+			size = <0 0x3c000000>;
+			linux,cma-default;
+			reusable;
+		};
+	};
+
+	sound-wm8904 {
+		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 = <&esai0>;
+		};
+	};
+};
+
+&acm {
+	status = "okay";
+};
+
+&asrc0 {
+	fsl,asrc-rate  = <48000>;
+	status = "okay";
+};
+
+&asrc1 {
+	fsl,asrc-rate = <48000>;
+	status = "okay";
+};
+
+&cm41_intmux {
+	status = "okay";
+};
+
+&esai0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esai0>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+			<&esai0_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div0_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <49152000>, <24576000>, <49152000>;
+	status = "okay";
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1>;
+	/*
+	 * The required RGMII TX and RX 2ns delays are implemented directly
+	 * in hardware via passive delay elements on the SOM PCB.
+	 * No delay configuration is needed in software via PHY driver.
+	 */
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy@4 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <4>;
+			reset-gpios = <&lsio_gpio2 28 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <20000>;
+			vddio-supply = <&reg_phy_vddio>;
+		};
+	};
+};
+
+&gpio0_mipi_csi0 {
+	status = "disabled";
+};
+
+&gpio0_mipi_csi1 {
+	status = "disabled";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	wm8904: codec@1a {
+		compatible = "wlf,wm8904";
+		reg = <0x1a>;
+		#sound-dai-cells = <0>;
+		clocks = <&mclkout0_lpcg 0>;
+		clock-names = "mclk";
+		assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+				<&mclkout0_lpcg 0>;
+		assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;
+		AVDD-supply = <&reg_audio_supply>;
+		CPVDD-supply = <&reg_audio_supply>;
+		DBVDD-supply = <&reg_audio_supply>;
+		DCVDD-supply = <&reg_audio_supply>;
+		MICVDD-supply = <&reg_audio_supply>;
+		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>;
+	};
+};
+
+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&mu_m0{
+	status = "okay";
+};
+
+&mu1_m0{
+	status = "okay";
+};
+
+&mu2_m0{
+	status = "okay";
+};
+
+&rtc {
+	status = "disabled";
+};
+
+&sai6 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI6_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai6_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&sai7 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI7_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai7_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&thermal_zones {
+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;
+				type = "critical";
+			};
+		};
+		cooling-maps {
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+	};
+};
+
+/* eMMC */
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_esai0: esai0grp {
+		fsl,pins = <
+			IMX8QM_ESAI0_FSR_AUD_ESAI0_FSR				0xc6000040
+			IMX8QM_ESAI0_FST_AUD_ESAI0_FST				0xc6000040
+			IMX8QM_ESAI0_SCKR_AUD_ESAI0_SCKR			0xc6000040
+			IMX8QM_ESAI0_SCKT_AUD_ESAI0_SCKT			0xc6000040
+			IMX8QM_ESAI0_TX0_AUD_ESAI0_TX0				0xc6000040
+			IMX8QM_ESAI0_TX5_RX0_AUD_ESAI0_TX5_RX0			0xc6000040
+			IMX8QM_MCLK_OUT0_AUD_ESAI0_TX_HF_CLK			0xc600004c
+		>;
+	};
+
+	pinctrl_fec1: fec1grp {
+		fsl,pins = <
+			IMX8QM_ENET0_MDC_CONN_ENET0_MDC				0x06000048
+			IMX8QM_ENET0_MDIO_CONN_ENET0_MDIO			0x06000048
+			IMX8QM_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL	0x06000048
+			IMX8QM_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC		0x06000048
+			IMX8QM_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0		0x06000048
+			IMX8QM_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1		0x06000048
+			IMX8QM_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2		0x06000048
+			IMX8QM_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3		0x06000048
+			IMX8QM_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC		0x06000048
+			IMX8QM_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL	0x06000048
+			IMX8QM_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0		0x06000048
+			IMX8QM_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1		0x06000048
+			IMX8QM_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2		0x06000048
+			IMX8QM_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3		0x06000048
+			IMX8QM_ESAI0_TX2_RX3_LSIO_GPIO2_IO28			0x06000028
+		>;
+	};
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			IMX8QM_ESAI1_FSR_LSIO_GPIO2_IO04			0x00000041
+			IMX8QM_ESAI1_FST_LSIO_GPIO2_IO05			0x00000041
+			IMX8QM_ESAI1_SCKR_LSIO_GPIO2_IO06			0x00000041
+			IMX8QM_ESAI1_SCKT_LSIO_GPIO2_IO07			0x00000041
+			IMX8QM_SPDIF0_EXT_CLK_LSIO_GPIO2_IO16			0x00000041
+		>;
+	};
+
+	pinctrl_i2c0: i2c0grp {
+		fsl,pins = <
+			IMX8QM_HDMI_TX0_TS_SCL_DMA_I2C0_SCL			0xc6000020
+			IMX8QM_HDMI_TX0_TS_SDA_DMA_I2C0_SDA			0xc6000020
+		>;
+	};
+
+	pinctrl_lpuart1: lpuart1grp {
+		fsl,pins = <
+			IMX8QM_UART1_RX_DMA_UART1_RX				0x06000020
+			IMX8QM_UART1_TX_DMA_UART1_TX				0x06000020
+			IMX8QM_UART1_CTS_B_DMA_UART1_RTS_B			0x06000020
+			IMX8QM_UART1_RTS_B_DMA_UART1_CTS_B			0x06000020
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000041
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000021
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000021
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000021
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000021
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000021
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000021
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000021
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000021
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000021
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000041
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000021
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000040
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000020
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000020
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000020
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000020
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000020
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000020
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000020
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000020
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000020
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000040
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+		fsl,pins = <
+			IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK				0x06000040
+			IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD				0x00000020
+			IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0			0x00000020
+			IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1			0x00000020
+			IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2			0x00000020
+			IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3			0x00000020
+			IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4			0x00000020
+			IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5			0x00000020
+			IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6			0x00000020
+			IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7			0x00000020
+			IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE			0x06000040
+			IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000041
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000021
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000021
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000021
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000021
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000021
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3100mhzgrp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000040
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000020
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000020
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000020
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000020
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000020
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK			0x06000040
+			IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD			0x00000020
+			IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0			0x00000020
+			IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1			0x00000020
+			IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2			0x00000020
+			IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3			0x00000020
+		>;
+	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			/* GPIOs used by user space WiFi init */
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};
Signature · 1 line
2.47.3
AI review
#3 lore raw

Re: [PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider: - [High] Audio master clocks (MCLK) are left unconfigured, and audio baud rates are erroneously applied to…

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Audio master clocks (MCLK) are left unconfigured, and audio baud rates are erroneously applied to peripheral bus clocks (IPG) due to incorrect LPCG clock indices.
- [High] Conflicting assigned clock rates for shared audio PLL MST_BUS.
- [High] Codec MCLK pinmux connects to ESAI0 high-frequency clock instead of the configured LPCG clock.
- [High] The Continuous Memory Allocator (CMA) pool allocation range is strictly out-of-bounds relative to the default declared system memory, breaking CMA initialization on 1GB SOM variants.
- [High] The PMIC thermal mitigation map ignores the high-power Cortex-A72 cores, defeating effective thermal throttling.
- [Medium] WiFi and Bluetooth enable/power sequencing is explicitly deferred to user space instead of being structurally modeled in the device tree.
--

--- Patch [2]: [PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax --- commit e14b5ef256af728dc56444b803ea5575d3814182

Author: Stefano Radaelli <[email protected]>
Date:   Wed Jul 15 11:08:11 2026 +0000

arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Add device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module. This SOM is designed to be used with various carrier boards.

Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +0 -0
new file mode 100644
index 0000000000000..08b02173b780c
@@ -0,0 +1,530 @@

[ ... ]

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x40000000>;
+	};

[ ... ]

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 124

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+		/* global autoconfigured region for contiguous allocations */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0 0xc0000000 0 0x3c000000>;

[Severity: High]
Does this alloc-ranges declaration break the Continuous Memory Allocator (CMA) initialization on 1GB SOM variants?

The declared 1GB system memory ends at 0xc0000000, while this alloc-ranges property forces CMA to find memory strictly starting at 0xc0000000, which would sit completely outside physical RAM on a 1GB board.

Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +5 -0
+			size = <0 0x3c000000>;
+			linux,cma-default;
+			reusable;
+		};
+	};

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 188

Quoted 11 lines

+&esai0 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esai0>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+			<&esai0_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div0_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <49152000>, <24576000>, <49152000>;

[Severity: High]
Does this configuration incorrectly alter the IPG clock instead of the MCLK?

The assigned-clocks list uses <&esai0_lpcg 0>, which is IMX_LPCG_CLK_0 (the peripheral bus IPG clock). The master clock (MCLK) would normally be at index 16 (IMX_LPCG_CLK_4).

Additionally, is it safe to assign 24.576 MHz to IMX_SC_PM_CLK_MST_BUS here? Later in the file, the wm8904 codec driver assigns 12.288 MHz to this exact same shared audio PLL MST_BUS clock. Whichever device probes last will overwrite the other's frequency, likely causing audio distortion or failure.

Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	status = "okay";
+};

[ ... ]

Quoted 7 lines

+&i2c0 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +6 -0
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	wm8904: codec@1a {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 243

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+		compatible = "wlf,wm8904";
+		reg = <0x1a>;
+		#sound-dai-cells = <0>;
+		clocks = <&mclkout0_lpcg 0>;
+		clock-names = "mclk";
+		assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+				<&mclkout0_lpcg 0>;
+		assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;

[Severity: High]
This assigns 12.288 MHz to IMX_SC_PM_CLK_MST_BUS, which conflicts with the 24.576 MHz assigned in &esai0.

Also, the codec driver expects to control its clock via <&mclkout0_lpcg 0>. However, looking down at pinctrl_esai0, the physical pin is muxed to AUD_ESAI0_TX_HF_CLK (ESAI0's internal clock) instead of AUD_ACM_MCLK_OUT0. Will this leave the codec without the expected master clock source?

Quoted 1 line
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +1 -0
+		AVDD-supply = <&reg_audio_supply>;

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 275

Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};

[Severity: Medium]
Since this UART is used for Bluetooth, does it need a 'bluetooth' child node to properly describe power and enable dependencies?

Without it, kernel-level power management (like suspend/resume and rfkill) will not be able to power down the module.

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 300

Quoted 8 lines

+&sai6 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI6_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai6_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;

[Severity: High]
Similar to the esai0 node, this assigns the audio baud rate to clock index 0 (IPG clock) instead of index 16 (MCLK). Could this cause bus instability?

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 312

Quoted 12 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +12 -0
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&sai7 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI7_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai7_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;

[Severity: High]
As with esai0 and sai6, this applies the 98.304 MHz rate to <&sai7_lpcg 0> (IPG clock) instead of index 16.

Quoted 18 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +18 -0
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&thermal_zones {
+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 340

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+				type = "critical";
+			};
+		};
+		cooling-maps {
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;

[Severity: High]
Should the high-power Cortex-A72 cores (A72_0 and A72_1) be included in this cooling map?

If the A72 cores are omitted, they will remain unthrottled during a PMIC thermal event. Throttling only the low-power A53 cores might fail to reduce current draw sufficiently to prevent a hardware thermal shutdown.

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+			};
+		};
+	};
+};

[ ... ]

Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 373

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};

[Severity: Medium]
Is it intended to leave this Wi-Fi SDIO bus without a vmmc-supply or mmc-pwrseq regulator?

By leaving this out and explicitly reserving the enable GPIOs for user-space control (as seen below in pinctrl_wifi), kernel-level power management is bypassed. This will break suspend/resume and rfkill functionality because the MMC/SDIO core cannot power down or up the module itself.

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 387

Quoted 9 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +9 -0
+	pinctrl_esai0: esai0grp {
+		fsl,pins = <
+			IMX8QM_ESAI0_FSR_AUD_ESAI0_FSR				0xc6000040
+			IMX8QM_ESAI0_FST_AUD_ESAI0_FST				0xc6000040
+			IMX8QM_ESAI0_SCKR_AUD_ESAI0_SCKR			0xc6000040
+			IMX8QM_ESAI0_SCKT_AUD_ESAI0_SCKT			0xc6000040
+			IMX8QM_ESAI0_TX0_AUD_ESAI0_TX0				0xc6000040
+			IMX8QM_ESAI0_TX5_RX0_AUD_ESAI0_TX5_RX0			0xc6000040
+			IMX8QM_MCLK_OUT0_AUD_ESAI0_TX_HF_CLK			0xc600004c

[Severity: High]
As mentioned earlier, the wm8904 codec driver configures <&mclkout0_lpcg 0> for its clock. However, this pinmux connects the pin to AUD_ESAI0_TX_HF_CLK rather than AUD_ACM_MCLK_OUT0, meaning the codec will likely receive the wrong clock source.

Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+		>;
+	};

[ ... ]

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			/* GPIOs used by user space WiFi init */
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
#4 lore raw

Re: [PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Quoted 39 lines · On Wed, Jul 15, 2026 at 11:21:10AM +0000, [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Audio master clocks (MCLK) are left unconfigured, and audio baud rates are erroneously applied to peripheral bus clocks (IPG) due to incorrect LPCG clock indices.
- [High] Conflicting assigned clock rates for shared audio PLL MST_BUS.
- [High] Codec MCLK pinmux connects to ESAI0 high-frequency clock instead of the configured LPCG clock.
- [High] The Continuous Memory Allocator (CMA) pool allocation range is strictly out-of-bounds relative to the default declared system memory, breaking CMA initialization on 1GB SOM variants.
- [High] The PMIC thermal mitigation map ignores the high-power Cortex-A72 cores, defeating effective thermal throttling.
- [Medium] WiFi and Bluetooth enable/power sequencing is explicitly deferred to user space instead of being structurally modeled in the device tree.
--

--- Patch [2]: [PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax --- commit e14b5ef256af728dc56444b803ea5575d3814182

Author: Stefano Radaelli <[email protected]>
Date:   Wed Jul 15 11:08:11 2026 +0000

arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Add device tree support for the Variscite VAR-SOM-MX8 QuadMax system on module. This SOM is designed to be used with various carrier boards.

Link https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +0 -0
new file mode 100644
index 0000000000000..08b02173b780c
@@ -0,0 +1,530 @@

[ ... ]

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x40000000>;
+	};

[ ... ]

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;

[ ... ]

Quoted 8 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 124

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+		/* global autoconfigured region for contiguous allocations */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0 0xc0000000 0 0x3c000000>;

[Severity: High]
Does this alloc-ranges declaration break the Continuous Memory Allocator (CMA) initialization on 1GB SOM variants?

Do your board have 1GB variant?

Quoted 26 lines

The declared 1GB system memory ends at 0xc0000000, while this alloc-ranges property forces CMA to find memory strictly starting at 0xc0000000, which would sit completely outside physical RAM on a 1GB board.

Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +5 -0
+			size = <0 0x3c000000>;
+			linux,cma-default;
+			reusable;
+		};
+	};

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 188

Quoted 11 lines

+&esai0 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esai0>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+			<&esai0_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div0_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <49152000>, <24576000>, <49152000>;

[Severity: High]
Does this configuration incorrectly alter the IPG clock instead of the MCLK?

Quoted 3 lines

The assigned-clocks list uses <&esai0_lpcg 0>, which is IMX_LPCG_CLK_0 (the peripheral bus IPG clock). The master clock (MCLK) would normally be at index 16 (IMX_LPCG_CLK_4).

Yes, 0 is wrong.

Quoted 154 lines

Additionally, is it safe to assign 24.576 MHz to IMX_SC_PM_CLK_MST_BUS here? Later in the file, the wm8904 codec driver assigns 12.288 MHz to this exact same shared audio PLL MST_BUS clock. Whichever device probes last will overwrite the other's frequency, likely causing audio distortion or failure.

Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+	status = "okay";
+};

[ ... ]

Quoted 7 lines

+&i2c0 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +6 -0
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	wm8904: codec@1a {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 243

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+		compatible = "wlf,wm8904";
+		reg = <0x1a>;
+		#sound-dai-cells = <0>;
+		clocks = <&mclkout0_lpcg 0>;
+		clock-names = "mclk";
+		assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+				<&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+				<&mclkout0_lpcg 0>;
+		assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;

[Severity: High]
This assigns 12.288 MHz to IMX_SC_PM_CLK_MST_BUS, which conflicts with the 24.576 MHz assigned in &esai0.

Also, the codec driver expects to control its clock via <&mclkout0_lpcg 0>. However, looking down at pinctrl_esai0, the physical pin is muxed to AUD_ESAI0_TX_HF_CLK (ESAI0's internal clock) instead of AUD_ACM_MCLK_OUT0. Will this leave the codec without the expected master clock source?

Quoted 1 line
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +1 -0
+		AVDD-supply = <&reg_audio_supply>;

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 275

Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+/* Bluetooth */
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart1>;
+	uart-has-rtscts;
+	status = "okay";
+};

[Severity: Medium]
Since this UART is used for Bluetooth, does it need a 'bluetooth' child node to properly describe power and enable dependencies?

Without it, kernel-level power management (like suspend/resume and rfkill) will not be able to power down the module.

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 300

Quoted 8 lines

+&sai6 {

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI6_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai6_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;

[Severity: High]
Similar to the esai0 node, this assigns the audio baud rate to clock index 0 (IPG clock) instead of index 16 (MCLK). Could this cause bus instability?

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 312

Quoted 12 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +12 -0
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&sai7 {
+	assigned-clocks = <&acm IMX_ADMA_ACM_SAI7_MCLK_SEL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+			<&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+			<&sai7_lpcg 0>;
+	assigned-clock-parents = <&aud_pll_div1_lpcg 0>;
+	assigned-clock-rates = <0>, <786432000>, <98304000>, <24576000>, <98304000>;

[Severity: High]
As with esai0 and sai6, this applies the 98.304 MHz rate to <&sai7_lpcg 0> (IPG clock) instead of index 16.

Quoted 18 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +18 -0
+	fsl,sai-asynchronous;
+	status = "okay";
+};
+
+&thermal_zones {
+	pmic-thermal {
+		polling-delay-passive = <250>;
+		polling-delay = <2000>;
+		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+		trips {
+			pmic_alert0: trip0 {
+				temperature = <110000>;
+				hysteresis = <2000>;
+				type = "passive";
+			};
+			pmic_crit0: trip1 {
+				temperature = <125000>;
+				hysteresis = <2000>;

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 340

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+				type = "critical";
+			};
+		};
+		cooling-maps {
+			map0 {
+				trip = <&pmic_alert0>;
+				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;

[Severity: High]
Should the high-power Cortex-A72 cores (A72_0 and A72_1) be included in this cooling map?

If the A72 cores are omitted, they will remain unthrottled during a PMIC thermal event. Throttling only the low-power A53 cores might fail to reduce current draw sufficiently to prevent a hardware thermal shutdown.

Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +4 -0
+			};
+		};
+	};
+};

[ ... ]

Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +7 -0
+/* WIFI */
+&usdhc3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 373

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+	};
+};

[Severity: Medium]
Is it intended to leave this Wi-Fi SDIO bus without a vmmc-supply or mmc-pwrseq regulator?

By leaving this out and explicitly reserving the enable GPIOs for user-space control (as seen below in pinctrl_wifi), kernel-level power management is bypassed. This will break suspend/resume and rfkill functionality because the MMC/SDIO core cannot power down or up the module itself.

[ ... ]

Quoted 15 lines

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 387

Quoted 9 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +9 -0
+	pinctrl_esai0: esai0grp {
+		fsl,pins = <
+			IMX8QM_ESAI0_FSR_AUD_ESAI0_FSR				0xc6000040
+			IMX8QM_ESAI0_FST_AUD_ESAI0_FST				0xc6000040
+			IMX8QM_ESAI0_SCKR_AUD_ESAI0_SCKR			0xc6000040
+			IMX8QM_ESAI0_SCKT_AUD_ESAI0_SCKT			0xc6000040
+			IMX8QM_ESAI0_TX0_AUD_ESAI0_TX0				0xc6000040
+			IMX8QM_ESAI0_TX5_RX0_AUD_ESAI0_TX5_RX0			0xc6000040
+			IMX8QM_MCLK_OUT0_AUD_ESAI0_TX_HF_CLK			0xc600004c

[Severity: High]
As mentioned earlier, the wm8904 codec driver configures <&mclkout0_lpcg 0> for its clock. However, this pinmux connects the pin to AUD_ESAI0_TX_HF_CLK rather than AUD_ACM_MCLK_OUT0, meaning the codec will likely receive the wrong clock source.

Please double check this

Frank

Quoted 17 lines
Quoted 3 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +2 -0
+		>;
+	};

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi line 530

Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi new file +10 -0
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			/* GPIOs used by user space WiFi init */
+			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
+			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
+			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
+			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
+		>;
+	};
+};

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

author
#5 lore raw

PATCH v3 3/3 arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

In reply to Stefano Radaelli

From: Stefano Radaelli <[email protected]>

Add device tree support for the Variscite Symphony carrier board with the VAR-SOM-MX8 QuadMax system on module.

The Symphony board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
- PCIE support

Link https://variscite.com/carrier-boards/symphony-board/
Signed-off-by Stefano Radaelli <[email protected]>

---
v2->v3:
- Fix led typo
- Moved reset-gpios in pciea_port0
- Removed wrong captouch pinctrl gpio

v1->v2:
- Fix ptn5150 interrupt
- Fix ecspi1 cs gpio

 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx8qm-var-som-symphony.dts | 490 ++++++++++++++++++
 2 files changed, 491 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts
arch/arm64/boot/dts/freescale/Makefile +1 -0
index 430085123b4e..ceb31556a8c0 100644
@@ -540,6 +540,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.1.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.2.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-mek.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qm-tqma8qm-mba8x.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qm-var-som-symphony.dtb
 
 imx8qm-mek-ov5640-csi0-dtbs := imx8qm-mek.dtb imx8qm-mek-ov5640-csi0.dtbo
 dtb-${CONFIG_ARCH_MXC} += imx8qm-mek-ov5640-csi0.dtb
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +490 -0

490 lines not on this page · raw message

Signature · 1 line
2.47.3
AI review
#6 lore raw

Re: [PATCH v3 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Ethernet PHY is unpowered during MDIO bus scan due to decoupled phy-supply and MDIO parent --

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Ethernet PHY is unpowered during MDIO bus scan due to decoupled phy-supply and MDIO parent --

--- Patch [3]: [PATCH v3 3/3] arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board --- commit ac21a70e1bd0bf7f486143508c499cc45337cbf8
Author: Stefano Radaelli <[email protected]>

arm64: dts: imx8qm-var-som: Add support for Variscite Symphony board

This commit adds device tree support for the Variscite Symphony carrier board equipped with the VAR-SOM-MX8 QuadMax system on module. It defines various peripherals including uSD Card, USB, Gigabit Ethernet, UART, SPI, I2C interfaces, and PCIe.

Link https://variscite.com/carrier-boards/symphony-board/
Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +0 -0
new file mode 100644
index 0000000000000..7c7fc8958efc0

[ ... ]

Quoted 9 lines

+&fec1 {

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +8 -0
+	mdio {
+		ethphy1: ethernet-phy@5 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <5>;
+			vddio-supply = <&reg_phy_vddio>;
+			reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100000>;

[ ... ]

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts line 160

Quoted 11 lines

+&fec2 {

arch/arm64/boot/dts/freescale/imx8qm-var-som-symphony.dts new file +10 -0
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec2>;
+	/*
+	 * The required RGMII TX and RX 2ns delays are implemented directly
+	 * in hardware via passive delay elements on the SOM PCB.
+	 * No delay configuration is needed in software via PHY driver.
+	 */
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy1>;
+	phy-supply = <&reg_fec_phy>;

[Severity: High]
Will this PHY fail to probe because it is unpowered during the MDIO bus scan?

Since ethphy1 is defined as a child of the fec1 MDIO bus, fec1 initiates the PHY probe. However, its power supply (reg_fec_phy) is coupled to fec2 here.

When fec1 probes and registers its MDIO bus, it scans for PHYs. Because fec2 has not successfully probed yet (or deferred due to the missing PHY), reg_fec_phy will be OFF.

The MDIO core will fail to read the PHY ID of the unpowered ethphy1 and silently skip registering it. When fec2 eventually probes and enables the regulator, it will likely fail to connect because ethphy1 was never registered.

Does phy-supply need to be moved to the MDIO node or ethphy1 directly so it gets powered on before the MDIO bus is scanned?

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3