[PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[YijieYang]

From: Yijie Yang <yijie.yang@oss.qualcomm.com>

Introduce the device tree, DT bindings, and driver modifications required
to bring up the PURWA-IOT-EVK evaluation board.

Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
the IQ-X SoC series. Consequently, the two common files in this series are
prefixed with 'iq-x-iot' to reflect this relationship.

PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
except for differences in the BOM. As a result, most of the DTS can be
shared between them.

The changes focus on two key hardware components: the PURWA-IOT-SOM and
the PURWA-IOT-EVK carrier board.

Hardware delta between Hamoa and Purwa:
- Display: Purwa’s display uses a different number of clocks, and its
  frequency differs from Hamoa.
- GPU: Purwa requires a separate firmware compared to Hamoa.
- USB0: Purwa uses a PS8833 retimer, while Hamoa uses an FSUSB42 as the
  SBU switch.

The PURWA-IOT-SOM is a compact System on Module that integrates the SoC,
GPIOs, and PMICs. It is designed to be modular and can be paired with
various carrier boards to support different use cases.

The PURWA-IOT-EVK is one such carrier board, designed for IoT scenarios.
It provides essential peripherals such as UART, on-board PMICs, and
USB-related components. Together, these components form a flexible and
scalable platform, and the changes enable their initial bring-up through
proper device tree configuration and driver support.

Features added and enabled:
- UART
- On-board regulators
- Regulators on the SOM
- PMIC GLINK
- USB0 through USB6 and their PHYs
- Embedded USB (eUSB) repeaters
- USB Type-C mux
- PCIe6a and its PHY
- PCIe4 and its PHY
- Reserved memory regions
- Pinctrl
- NVMe
- ADSP, CDSP
- WLAN, Bluetooth (M.2 interface)
- USB DisplayPort
- Graphics
- Audio

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
Yijie Yang (4):
      firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK
      dt-bindings: arm: qcom: Document PURWA-IOT-EVK board
      arm64: dts: qcom: Commonize IQ-X-IOT DTSI
      arm64: dts: qcom: Add base PURWA-IOT-EVK board

 Documentation/devicetree/bindings/arm/qcom.yaml |    6 +
 arch/arm64/boot/dts/qcom/Makefile               |    1 +
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts      | 1188 +----------------------
 arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi     |  607 +-----------
 arch/arm64/boot/dts/qcom/iq-x-iot-evk.dtsi      | 1174 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/iq-x-iot-som.dtsi      |  609 ++++++++++++
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts      |  100 ++
 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi     |   11 +
 drivers/firmware/qcom/qcom_scm.c                |    1 +
 9 files changed, 1920 insertions(+), 1777 deletions(-)
---
base-commit: bdedd93e9fe243f01c8277f81314560e352eeca8
change-id: 20251113-purwa-907ec75b4959

Best regards,
--  
Yijie Yang <yijie.yang@oss.qualcomm.com>

[PATCH 1/4] firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK

[YijieYang]

From: Yijie Yang <yijie.yang@oss.qualcomm.com>

Add the Purwa-IoT-EVK board to the list to enable access to EFI variables.

Guarantee that subsystems relying on SCM services can access secure-world
features. This change improves reliability and prevents missing functionality
or boot-time issues by making service availability explicit.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 1a6f85e463e0..1fed7a81bd29 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2010,6 +2010,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "microsoft,romulus13", },
 	{ .compatible = "microsoft,romulus15", },
 	{ .compatible = "qcom,hamoa-iot-evk" },
+	{ .compatible = "qcom,purwa-iot-evk" },
 	{ .compatible = "qcom,sc8180x-primus" },
 	{ .compatible = "qcom,x1e001de-devkit" },
 	{ .compatible = "qcom,x1e80100-crd" },
-- 
2.34.1

[PATCH 2/4] dt-bindings: arm: qcom: Document PURWA-IOT-EVK board

[YijieYang]

From: Yijie Yang <yijie.yang@oss.qualcomm.com>

Document the device tree bindings for the PURWA-IOT-EVK board, which
uses the Qualcomm X1P42100 SoC. Split the common parts of the SoM and
carrier boards for HAMOA and PURWA into separate files for better
modularity.

Introduce the IQ-X-IOT series here, as both HAMOA and PURWA belong to
Qualcomm’s IQ-X family. For more details on IQ-X series, see:
https://www.qualcomm.com/internet-of-things/products/iq-x-series

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d84bd3bca201..5797bbfac9a2 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1089,6 +1089,12 @@ properties:
           - const: qcom,hamoa-iot-som
           - const: qcom,x1e80100
 
+      - items:
+          - enum:
+              - qcom,purwa-iot-evk
+          - const: qcom,purwa-iot-som
+          - const: qcom,x1p42100
+
       - items:
           - enum:
               - asus,zenbook-a14-ux3407qa-lcd
-- 
2.34.1

[PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[YijieYang]

From: Yijie Yang <yijie.yang@oss.qualcomm.com>

HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
the common components into separate files for better maintainability.

PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
except for differences in the BOM. The differences between the two boards
include the following:
- USB0 on Purwa uses the PS8833 as a retimer, while on Hamoa it uses the
  FSUSB42 as an SBU mode selector.
- Purwa has only one camera, whereas Hamoa includes two.
- Purwa provides a 4-lane PCIe3 interface, while Hamoa offers an 8-lane
  configuration.
- The videos on Purwa and Hamoa differ because their clocks and frequencies
  are not aligned.

Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
the IQ-X SoC series. Consequently, the two common files in this series are
prefixed with 'iq-x-iot' to reflect this relationship.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts    | 1328 ++---------------
 arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi   |  633 +-------
 .../{hamoa-iot-evk.dts => iq-x-iot-evk.dtsi}  |   74 +-
 .../{hamoa-iot-som.dtsi => iq-x-iot-som.dtsi} |    9 -
 4 files changed, 104 insertions(+), 1940 deletions(-)
 rewrite arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts (95%)
 rewrite arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi (98%)
 copy arch/arm64/boot/dts/qcom/{hamoa-iot-evk.dts => iq-x-iot-evk.dtsi} (94%)
 copy arch/arm64/boot/dts/qcom/{hamoa-iot-som.dtsi => iq-x-iot-som.dtsi} (99%)

diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
dissimilarity index 95%
index 36dd6599402b..418d8a6c573b 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -1,1242 +1,86 @@
-// SPDX-License-Identifier: BSD-3-Clause
-/*
- * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
- */
-
-/dts-v1/;
-
-#include "hamoa-iot-som.dtsi"
-
-/ {
-	model = "Qualcomm Technologies, Inc. Hamoa IoT EVK";
-	compatible = "qcom,hamoa-iot-evk", "qcom,hamoa-iot-som", "qcom,x1e80100";
-	chassis-type = "embedded";
-
-	aliases {
-		serial0 = &uart21;
-		serial1 = &uart14;
-	};
-
-	wcd938x: audio-codec {
-		compatible = "qcom,wcd9385-codec";
-
-		pinctrl-0 = <&wcd_default>;
-		pinctrl-names = "default";
-
-		reset-gpios = <&tlmm 191 GPIO_ACTIVE_LOW>;
-
-		qcom,micbias1-microvolt = <1800000>;
-		qcom,micbias2-microvolt = <1800000>;
-		qcom,micbias3-microvolt = <1800000>;
-		qcom,micbias4-microvolt = <1800000>;
-		qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000
-							 500000 500000 500000 500000>;
-		qcom,mbhc-headset-vthreshold-microvolt = <1700000>;
-		qcom,mbhc-headphone-vthreshold-microvolt = <50000>;
-		qcom,rx-device = <&wcd_rx>;
-		qcom,tx-device = <&wcd_tx>;
-
-		vdd-buck-supply = <&vreg_l15b_1p8>;
-		vdd-rxtx-supply = <&vreg_l15b_1p8>;
-		vdd-io-supply = <&vreg_l15b_1p8>;
-		vdd-mic-bias-supply = <&vreg_bob1>;
-
-		#sound-dai-cells = <1>;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	pmic-glink {
-		compatible = "qcom,x1e80100-pmic-glink",
-			     "qcom,sm8550-pmic-glink",
-			     "qcom,pmic-glink";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
-				    <&tlmm 123 GPIO_ACTIVE_HIGH>,
-				    <&tlmm 125 GPIO_ACTIVE_HIGH>;
-
-		connector@0 {
-			compatible = "usb-c-connector";
-			reg = <0>;
-			power-role = "dual";
-			data-role = "dual";
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-
-					pmic_glink_ss0_hs_in: endpoint {
-						remote-endpoint = <&usb_1_ss0_dwc3_hs>;
-					};
-				};
-
-				port@1 {
-					reg = <1>;
-
-					pmic_glink_ss0_ss_in: endpoint {
-						remote-endpoint = <&usb_1_ss0_qmpphy_out>;
-					};
-				};
-
-				port@2 {
-					reg = <2>;
-
-					pmic_glink_ss0_sbu: endpoint {
-						remote-endpoint = <&usb_1_ss0_sbu_mux>;
-					};
-				};
-			};
-		};
-
-		connector@1 {
-			compatible = "usb-c-connector";
-			reg = <1>;
-			power-role = "dual";
-			data-role = "dual";
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-
-					pmic_glink_ss1_hs_in: endpoint {
-						remote-endpoint = <&usb_1_ss1_dwc3_hs>;
-					};
-				};
-
-				port@1 {
-					reg = <1>;
-
-					pmic_glink_ss1_ss_in: endpoint {
-						remote-endpoint = <&retimer_ss1_ss_out>;
-					};
-				};
-
-				port@2 {
-					reg = <2>;
-
-					pmic_glink_ss1_con_sbu_in: endpoint {
-						remote-endpoint = <&retimer_ss1_con_sbu_out>;
-					};
-				};
-			};
-		};
-
-		connector@2 {
-			compatible = "usb-c-connector";
-			reg = <2>;
-			power-role = "dual";
-			data-role = "dual";
-
-			ports {
-				#address-cells = <1>;
-				#size-cells = <0>;
-
-				port@0 {
-					reg = <0>;
-
-					pmic_glink_ss2_hs_in: endpoint {
-						remote-endpoint = <&usb_1_ss2_dwc3_hs>;
-					};
-				};
-
-				port@1 {
-					reg = <1>;
-
-					pmic_glink_ss2_ss_in: endpoint {
-						remote-endpoint = <&retimer_ss2_ss_out>;
-					};
-				};
-
-				port@2 {
-					reg = <2>;
-
-					pmic_glink_ss2_con_sbu_in: endpoint {
-						remote-endpoint = <&retimer_ss2_con_sbu_out>;
-					};
-				};
-			};
-		};
-	};
-
-	vreg_edp_3p3: regulator-edp-3p3 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_EDP_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&edp_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_nvme: regulator-nvme {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_NVME_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 18 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&nvme_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	/* Left unused as the retimer is not used on this board. */
-	vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR0_1P15";
-		regulator-min-microvolt = <1150000>;
-		regulator-max-microvolt = <1150000>;
-
-		gpio = <&pmc8380_5_gpios 8 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb0_pwr_1p15_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr0_1p8: regulator-rtmr0-1p8 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR0_1P8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-
-		gpio = <&pm8550ve_9_gpios 8 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb0_1p8_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr0_3p3: regulator-rtmr0-3p3 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR0_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb0_3p3_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr1_1p15: regulator-rtmr1-1p15 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR1_1P15";
-		regulator-min-microvolt = <1150000>;
-		regulator-max-microvolt = <1150000>;
-
-		gpio = <&tlmm 188 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb1_pwr_1p15_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr1_1p8: regulator-rtmr1-1p8 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR1_1P8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-
-		gpio = <&tlmm 175 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb1_pwr_1p8_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr1_3p3: regulator-rtmr1-3p3 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR1_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 186 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb1_pwr_3p3_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr2_1p15: regulator-rtmr2-1p15 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR2_1P15";
-		regulator-min-microvolt = <1150000>;
-		regulator-max-microvolt = <1150000>;
-
-		gpio = <&tlmm 189 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb2_pwr_1p15_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr2_1p8: regulator-rtmr2-1p8 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR2_1P8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-
-		gpio = <&tlmm 126 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb2_pwr_1p8_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vreg_rtmr2_3p3: regulator-rtmr2-3p3 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_RTMR2_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 187 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&usb2_pwr_3p3_reg_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	vph_pwr: regulator-vph-pwr {
-		compatible = "regulator-fixed";
-
-		regulator-name = "vph_pwr";
-		regulator-min-microvolt = <3700000>;
-		regulator-max-microvolt = <3700000>;
-
-		regulator-always-on;
-		regulator-boot-on;
-	};
-
-	/*
-	 * TODO: These two regulators are actually part of the removable M.2
-	 * card and not the EVK mainboard. Need to describe this differently.
-	 * Functionally it works correctly, because all we need to do is to
-	 * turn on the actual 3.3V supply above.
-	 */
-	vreg_wcn_0p95: regulator-wcn-0p95 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_WCN_0P95";
-		regulator-min-microvolt = <950000>;
-		regulator-max-microvolt = <950000>;
-
-		vin-supply = <&vreg_wcn_3p3>;
-	};
-
-	vreg_wcn_1p9: regulator-wcn-1p9 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_WCN_1P9";
-		regulator-min-microvolt = <1900000>;
-		regulator-max-microvolt = <1900000>;
-
-		vin-supply = <&vreg_wcn_3p3>;
-	};
-
-	vreg_wcn_3p3: regulator-wcn-3p3 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_WCN_3P3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&wcn_sw_en>;
-		pinctrl-names = "default";
-
-		regulator-always-on;
-		regulator-boot-on;
-	};
-
-	vreg_wwan: regulator-wwan {
-		compatible = "regulator-fixed";
-
-		regulator-name = "SDX_VPH_PWR";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpio = <&tlmm 221 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-
-		pinctrl-0 = <&wwan_sw_en>;
-		pinctrl-names = "default";
-
-		regulator-boot-on;
-	};
-
-	sound {
-		compatible = "qcom,x1e80100-sndcard";
-		model = "X1E80100-EVK";
-		audio-routing = "WooferLeft IN", "WSA WSA_SPK1 OUT",
-				"TweeterLeft IN", "WSA WSA_SPK2 OUT",
-				"WooferRight IN", "WSA2 WSA_SPK2 OUT",
-				"TweeterRight IN", "WSA2 WSA_SPK2 OUT",
-				"IN1_HPHL", "HPHL_OUT",
-				"IN2_HPHR", "HPHR_OUT",
-				"AMIC2", "MIC BIAS2",
-				"VA DMIC0", "MIC BIAS3",
-				"VA DMIC1", "MIC BIAS3",
-				"VA DMIC2", "MIC BIAS1",
-				"VA DMIC3", "MIC BIAS1",
-				"TX SWR_INPUT1", "ADC2_OUTPUT";
-
-		wcd-playback-dai-link {
-			link-name = "WCD Playback";
-
-			codec {
-				sound-dai = <&wcd938x 0>, <&swr1 0>, <&lpass_rxmacro 0>;
-			};
-
-			cpu {
-				sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
-			};
-
-			platform {
-				sound-dai = <&q6apm>;
-			};
-		};
-
-		wcd-capture-dai-link {
-			link-name = "WCD Capture";
-
-			codec {
-				sound-dai = <&wcd938x 1>, <&swr2 1>, <&lpass_txmacro 0>;
-			};
-
-			cpu {
-				sound-dai = <&q6apmbedai TX_CODEC_DMA_TX_3>;
-			};
-
-			platform {
-				sound-dai = <&q6apm>;
-			};
-		};
-
-		wsa-dai-link {
-			link-name = "WSA Playback";
-
-			codec {
-				sound-dai = <&left_woofer>,
-					    <&left_tweeter>,
-					    <&swr0 0>,
-					    <&lpass_wsamacro 0>,
-					    <&right_woofer>,
-					    <&right_tweeter>,
-					    <&swr3 0>,
-					    <&lpass_wsa2macro 0>;
-			};
-
-			cpu {
-				sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
-			};
-
-			platform {
-				sound-dai = <&q6apm>;
-			};
-		};
-
-		va-dai-link {
-			link-name = "VA Capture";
-
-			codec {
-				sound-dai = <&lpass_vamacro 0>;
-			};
-
-			cpu {
-				sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
-			};
-
-			platform {
-				sound-dai = <&q6apm>;
-			};
-		};
-	};
-
-	usb-1-ss0-sbu-mux {
-		compatible = "onnn,fsusb42", "gpio-sbu-mux";
-
-		enable-gpios = <&tlmm 168 GPIO_ACTIVE_LOW>;
-		select-gpios = <&tlmm 167 GPIO_ACTIVE_HIGH>;
-
-		pinctrl-0 = <&usb_1_ss0_sbu_default>;
-		pinctrl-names = "default";
-
-		mode-switch;
-		orientation-switch;
-
-		port {
-			usb_1_ss0_sbu_mux: endpoint {
-				remote-endpoint = <&pmic_glink_ss0_sbu>;
-			};
-		};
-	};
-
-	wcn7850-pmu {
-		compatible = "qcom,wcn7850-pmu";
-
-		vdd-supply = <&vreg_wcn_0p95>;
-		vddio-supply = <&vreg_l15b_1p8>;
-		vddaon-supply = <&vreg_wcn_0p95>;
-		vdddig-supply = <&vreg_wcn_0p95>;
-		vddrfa1p2-supply = <&vreg_wcn_1p9>;
-		vddrfa1p8-supply = <&vreg_wcn_1p9>;
-
-		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
-		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
-
-		pinctrl-0 = <&wcn_bt_en>;
-		pinctrl-names = "default";
-
-		regulators {
-			vreg_pmu_rfa_cmn: ldo0 {
-				regulator-name = "vreg_pmu_rfa_cmn";
-			};
-
-			vreg_pmu_aon_0p59: ldo1 {
-				regulator-name = "vreg_pmu_aon_0p59";
-			};
-
-			vreg_pmu_wlcx_0p8: ldo2 {
-				regulator-name = "vreg_pmu_wlcx_0p8";
-			};
-
-			vreg_pmu_wlmx_0p85: ldo3 {
-				regulator-name = "vreg_pmu_wlmx_0p85";
-			};
-
-			vreg_pmu_btcmx_0p85: ldo4 {
-				regulator-name = "vreg_pmu_btcmx_0p85";
-			};
-
-			vreg_pmu_rfa_0p8: ldo5 {
-				regulator-name = "vreg_pmu_rfa_0p8";
-			};
-
-			vreg_pmu_rfa_1p2: ldo6 {
-				regulator-name = "vreg_pmu_rfa_1p2";
-			};
-
-			vreg_pmu_rfa_1p8: ldo7 {
-				regulator-name = "vreg_pmu_rfa_1p8";
-			};
-
-			vreg_pmu_pcie_0p9: ldo8 {
-				regulator-name = "vreg_pmu_pcie_0p9";
-			};
-
-			vreg_pmu_pcie_1p8: ldo9 {
-				regulator-name = "vreg_pmu_pcie_1p8";
-			};
-		};
-	};
-};
-
-&i2c1 {
-	clock-frequency = <400000>;
-	status = "okay";
-
-	typec-mux@8 {
-		compatible = "parade,ps8830";
-		reg = <0x08>;
-
-		clocks = <&rpmhcc RPMH_RF_CLK5>;
-
-		vdd-supply = <&vreg_rtmr2_1p15>;
-		vdd33-supply = <&vreg_rtmr2_3p3>;
-		vdd33-cap-supply = <&vreg_rtmr2_3p3>;
-		vddar-supply = <&vreg_rtmr2_1p15>;
-		vddat-supply = <&vreg_rtmr2_1p15>;
-		vddio-supply = <&vreg_rtmr2_1p8>;
-
-		reset-gpios = <&tlmm 185 GPIO_ACTIVE_LOW>;
-
-		pinctrl-0 = <&rtmr2_default>;
-		pinctrl-names = "default";
-
-		orientation-switch;
-		retimer-switch;
-
-		ports {
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			port@0 {
-				reg = <0>;
-
-				retimer_ss2_ss_out: endpoint {
-					remote-endpoint = <&pmic_glink_ss2_ss_in>;
-				};
-			};
-
-			port@1 {
-				reg = <1>;
-
-				retimer_ss2_ss_in: endpoint {
-					remote-endpoint = <&usb_1_ss2_qmpphy_out>;
-				};
-			};
-
-			port@2 {
-				reg = <2>;
-
-				retimer_ss2_con_sbu_out: endpoint {
-					remote-endpoint = <&pmic_glink_ss2_con_sbu_in>;
-				};
-			};
-		};
-	};
-};
-
-&i2c5 {
-	clock-frequency = <400000>;
-
-	status = "okay";
-
-	eusb3_repeater: redriver@47 {
-		compatible = "nxp,ptn3222";
-		reg = <0x47>;
-		#phy-cells = <0>;
-
-		vdd3v3-supply = <&vreg_l13b_3p0>;
-		vdd1v8-supply = <&vreg_l4b_1p8>;
-
-		reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
-
-		pinctrl-0 = <&eusb3_reset_n>;
-		pinctrl-names = "default";
-	};
-
-	eusb5_repeater: redriver@43 {
-		compatible = "nxp,ptn3222";
-		reg = <0x43>;
-		#phy-cells = <0>;
-
-		vdd3v3-supply = <&vreg_l13b_3p0>;
-		vdd1v8-supply = <&vreg_l4b_1p8>;
-
-		reset-gpios = <&tlmm 7 GPIO_ACTIVE_LOW>;
-
-		pinctrl-0 = <&eusb5_reset_n>;
-		pinctrl-names = "default";
-	};
-
-	eusb6_repeater: redriver@4f {
-		compatible = "nxp,ptn3222";
-		reg = <0x4f>;
-		#phy-cells = <0>;
-
-		vdd3v3-supply = <&vreg_l13b_3p0>;
-		vdd1v8-supply = <&vreg_l4b_1p8>;
-
-		reset-gpios = <&tlmm 184 GPIO_ACTIVE_LOW>;
-
-		pinctrl-0 = <&eusb6_reset_n>;
-		pinctrl-names = "default";
-	};
-};
-
-&i2c7 {
-	clock-frequency = <400000>;
-
-	status = "okay";
-
-	typec-mux@8 {
-		compatible = "parade,ps8830";
-		reg = <0x8>;
-
-		clocks = <&rpmhcc RPMH_RF_CLK4>;
-
-		vdd-supply = <&vreg_rtmr1_1p15>;
-		vdd33-supply = <&vreg_rtmr1_3p3>;
-		vdd33-cap-supply = <&vreg_rtmr1_3p3>;
-		vddar-supply = <&vreg_rtmr1_1p15>;
-		vddat-supply = <&vreg_rtmr1_1p15>;
-		vddio-supply = <&vreg_rtmr1_1p8>;
-
-		reset-gpios = <&tlmm 176 GPIO_ACTIVE_LOW>;
-
-		pinctrl-0 = <&rtmr1_default>;
-		pinctrl-names = "default";
-
-		retimer-switch;
-		orientation-switch;
-
-		ports {
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			port@0 {
-				reg = <0>;
-
-				retimer_ss1_ss_out: endpoint {
-					remote-endpoint = <&pmic_glink_ss1_ss_in>;
-				};
-			};
-
-			port@1 {
-				reg = <1>;
-
-				retimer_ss1_ss_in: endpoint {
-					remote-endpoint = <&usb_1_ss1_qmpphy_out>;
-				};
-			};
-
-			port@2 {
-				reg = <2>;
-
-				retimer_ss1_con_sbu_out: endpoint {
-					remote-endpoint = <&pmic_glink_ss1_con_sbu_in>;
-				};
-			};
-		};
-	};
-};
-
-&lpass_tlmm {
-	spkr_0_sd_n_active: spkr-0-sd-n-active-state {
-		pins = "gpio12";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-	};
-
-	spkr_1_sd_n_active: spkr-1-sd-n-active-state {
-		pins = "gpio13";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-	};
-
-	spkr_2_sd_n_active: spkr-2-sd-n-active-state {
-		pins = "gpio17";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-	};
-
-	spkr_3_sd_n_active: spkr-3-sd-n-active-state {
-		pins = "gpio18";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-	};
-};
-
-&lpass_vamacro {
-	pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
-	pinctrl-names = "default";
-
-	vdd-micb-supply = <&vreg_l1b_1p8>;
-	qcom,dmic-sample-rate = <4800000>;
-};
-
-&mdss {
-	status = "okay";
-};
-
-&mdss_dp0 {
-	status = "okay";
-};
-
-&mdss_dp0_out {
-	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-};
-
-&mdss_dp1 {
-	status = "okay";
-};
-
-&mdss_dp1_out {
-	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-};
-
-&mdss_dp2 {
-	status = "okay";
-};
-
-&mdss_dp2_out {
-	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-};
-
-&mdss_dp3 {
-	/delete-property/ #sound-dai-cells;
-
-	pinctrl-0 = <&edp0_hpd_default>;
-	pinctrl-names = "default";
-
-	status = "okay";
-
-	aux-bus {
-		panel {
-			compatible = "edp-panel";
-			power-supply = <&vreg_edp_3p3>;
-
-			port {
-				edp_panel_in: endpoint {
-					remote-endpoint = <&mdss_dp3_out>;
-				};
-			};
-		};
-	};
-};
-
-&mdss_dp3_out {
-	data-lanes = <0 1 2 3>;
-	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-
-	remote-endpoint = <&edp_panel_in>;
-};
-
-&mdss_dp3_phy {
-	vdda-phy-supply = <&vreg_l3j_0p8>;
-	vdda-pll-supply = <&vreg_l2j_1p2>;
-
-	status = "okay";
-};
-
-&pcie6a {
-	vddpe-3v3-supply = <&vreg_nvme>;
-};
-
-&pm8550_gpios {
-	rtmr0_default: rtmr0-reset-n-active-state {
-		pins = "gpio10";
-		function = "normal";
-		power-source = <1>; /* 1.8V */
-		bias-disable;
-		input-disable;
-		output-enable;
-	};
-
-	usb0_3p3_reg_en: usb0-3p3-reg-en-state {
-		pins = "gpio11";
-		function = "normal";
-		power-source = <1>; /* 1.8V */
-		bias-disable;
-		input-disable;
-		output-enable;
-	};
-};
-
-&pm8550ve_9_gpios {
-	usb0_1p8_reg_en: usb0-1p8-reg-en-state {
-		pins = "gpio8";
-		function = "normal";
-		power-source = <1>; /* 1.8V */
-		bias-disable;
-		input-disable;
-		output-enable;
-	};
-};
-
-&pmc8380_5_gpios {
-	usb0_pwr_1p15_reg_en: usb0-pwr-1p15-reg-en-state {
-		pins = "gpio8";
-		function = "normal";
-		power-source = <1>; /* 1.8V */
-		bias-disable;
-		input-disable;
-		output-enable;
-	};
-};
-
-&smb2360_0 {
-	status = "okay";
-};
-
-&smb2360_0_eusb2_repeater {
-	vdd18-supply = <&vreg_l3d_1p8>;
-	vdd3-supply = <&vreg_l2b_3p0>;
-};
-
-&smb2360_1 {
-	status = "okay";
-};
-
-&smb2360_1_eusb2_repeater {
-	vdd18-supply = <&vreg_l3d_1p8>;
-	vdd3-supply = <&vreg_l14b_3p0>;
-};
-
-&smb2360_2 {
-	status = "okay";
-};
-
-&smb2360_2_eusb2_repeater {
-	vdd18-supply = <&vreg_l3d_1p8>;
-	vdd3-supply = <&vreg_l8b_3p0>;
-};
-
-&swr0 {
-	status = "okay";
-
-	pinctrl-0 = <&wsa_swr_active>;
-	pinctrl-names = "default";
-
-	/* WSA8845, Left Woofer */
-	left_woofer: speaker@0,0 {
-		compatible = "sdw20217020400";
-		pinctrl-0 = <&spkr_0_sd_n_active>;
-		pinctrl-names = "default";
-		reg = <0 0>;
-		reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
-		#sound-dai-cells = <0>;
-		sound-name-prefix = "WooferLeft";
-		vdd-1p8-supply = <&vreg_l15b_1p8>;
-		vdd-io-supply = <&vreg_l12b_1p2>;
-		qcom,port-mapping = <1 2 3 7 10 13>;
-	};
-
-	/* WSA8845, Left Tweeter */
-	left_tweeter: speaker@0,1 {
-		compatible = "sdw20217020400";
-		pinctrl-0 = <&spkr_1_sd_n_active>;
-		pinctrl-names = "default";
-		reg = <0 1>;
-		reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
-		#sound-dai-cells = <0>;
-		sound-name-prefix = "TweeterLeft";
-		vdd-1p8-supply = <&vreg_l15b_1p8>;
-		vdd-io-supply = <&vreg_l12b_1p2>;
-		qcom,port-mapping = <4 5 6 7 11 13>;
-	};
-};
-
-&swr1 {
-	status = "okay";
-
-	/* WCD9385 RX */
-	wcd_rx: codec@0,4 {
-		compatible = "sdw20217010d00";
-		reg = <0 4>;
-		qcom,rx-port-mapping = <1 2 3 4 5>;
-	};
-};
-
-&swr2 {
-	status = "okay";
-
-	/* WCD9385 TX */
-	wcd_tx: codec@0,3 {
-		compatible = "sdw20217010d00";
-		reg = <0 3>;
-		qcom,tx-port-mapping = <2 2 3 4>;
-	};
-};
-
-&swr3 {
-	status = "okay";
-
-	pinctrl-0 = <&wsa2_swr_active>;
-	pinctrl-names = "default";
-
-	/* WSA8845, Right Woofer */
-	right_woofer: speaker@0,0 {
-		compatible = "sdw20217020400";
-		pinctrl-0 = <&spkr_2_sd_n_active>;
-		pinctrl-names = "default";
-		reg = <0 0>;
-		reset-gpios = <&lpass_tlmm 17 GPIO_ACTIVE_LOW>;
-		#sound-dai-cells = <0>;
-		sound-name-prefix = "WooferRight";
-		vdd-1p8-supply = <&vreg_l15b_1p8>;
-		vdd-io-supply = <&vreg_l12b_1p2>;
-		qcom,port-mapping = <1 2 3 7 10 13>;
-	};
-
-	/* WSA8845, Right Tweeter */
-	right_tweeter: speaker@0,1 {
-		compatible = "sdw20217020400";
-		pinctrl-0 = <&spkr_3_sd_n_active>;
-		pinctrl-names = "default";
-		reg = <0 1>;
-		reset-gpios = <&lpass_tlmm 18 GPIO_ACTIVE_LOW>;
-		#sound-dai-cells = <0>;
-		sound-name-prefix = "TweeterRight";
-		vdd-1p8-supply = <&vreg_l15b_1p8>;
-		vdd-io-supply = <&vreg_l12b_1p2>;
-		qcom,port-mapping = <4 5 6 7 11 13>;
-	};
-};
-
-&tlmm {
-	edp_reg_en: edp-reg-en-state {
-		pins = "gpio70";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-	};
-
-	eusb3_reset_n: eusb3-reset-n-state {
-		pins = "gpio6";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-		output-low;
-	};
-
-	eusb5_reset_n: eusb5-reset-n-state {
-		pins = "gpio7";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-pull-up;
-		output-low;
-	};
-
-	eusb6_reset_n: eusb6-reset-n-state {
-		pins = "gpio184";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-pull-up;
-		output-low;
-	};
-
-	nvme_reg_en: nvme-reg-en-state {
-		pins = "gpio18";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	rtmr1_default: rtmr1-reset-n-active-state {
-		pins = "gpio176";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	rtmr2_default: rtmr2-reset-n-active-state {
-		pins = "gpio185";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb1_pwr_1p15_reg_en: usb1-pwr-1p15-reg-en-state {
-		pins = "gpio188";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb1_pwr_1p8_reg_en: usb1-pwr-1p8-reg-en-state {
-		pins = "gpio175";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb1_pwr_3p3_reg_en: usb1-pwr-3p3-reg-en-state {
-		pins = "gpio186";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb2_pwr_1p15_reg_en: usb2-pwr-1p15-reg-en-state {
-		pins = "gpio189";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb2_pwr_1p8_reg_en: usb2-pwr-1p8-reg-en-state {
-		pins = "gpio126";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb2_pwr_3p3_reg_en: usb2-pwr-3p3-reg-en-state {
-		pins = "gpio187";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
-		mode-pins {
-			pins = "gpio166";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-			output-high;
-		};
-
-		oe-n-pins {
-			pins = "gpio168";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-		};
-
-		sel-pins {
-			pins = "gpio167";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-		};
-	};
-
-	wcd_default: wcd-reset-n-active-state {
-		pins = "gpio191";
-		function = "gpio";
-		drive-strength = <16>;
-		bias-disable;
-		output-low;
-	};
-
-	wcn_bt_en: wcn-bt-en-state {
-		pins = "gpio116";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	wwan_sw_en: wwan-sw-en-state {
-		pins = "gpio221";
-		function = "gpio";
-		drive-strength = <4>;
-		bias-disable;
-	};
-
-	wcn_sw_en: wcn-sw-en-state {
-		pins = "gpio214";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-	};
-
-	/* Switches USB signal routing between the USB connector and the Wi-Fi card. */
-	wcn_usb_sw_n: wcn-usb-sw-n-state {
-		pins = "gpio225";
-		function = "gpio";
-		drive-strength = <2>;
-		bias-disable;
-		output-high;
-	};
-};
-
-&uart14 {
-	status = "okay";
-
-	bluetooth {
-		compatible = "qcom,wcn7850-bt";
-		max-speed = <3200000>;
-
-		vddaon-supply = <&vreg_pmu_aon_0p59>;
-		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
-		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
-		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
-		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
-		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
-		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
-	};
-};
-
-&uart21 {
-	compatible = "qcom,geni-debug-uart";
-
-	status = "okay";
-};
-
-&usb_1_ss0_dwc3_hs {
-	remote-endpoint = <&pmic_glink_ss0_hs_in>;
-};
-
-&usb_1_ss0_hsphy {
-	phys = <&smb2360_0_eusb2_repeater>;
-};
-
-&usb_1_ss0_qmpphy_out {
-	remote-endpoint = <&pmic_glink_ss0_ss_in>;
-};
-
-&usb_1_ss1_dwc3_hs {
-	remote-endpoint = <&pmic_glink_ss1_hs_in>;
-};
-
-&usb_1_ss1_hsphy {
-	phys = <&smb2360_1_eusb2_repeater>;
-};
-
-&usb_1_ss1_qmpphy_out {
-	remote-endpoint = <&retimer_ss1_ss_in>;
-};
-
-&usb_1_ss2_dwc3_hs {
-	remote-endpoint = <&pmic_glink_ss2_hs_in>;
-};
-
-&usb_1_ss2_hsphy {
-	phys = <&smb2360_2_eusb2_repeater>;
-};
-
-&usb_1_ss2_qmpphy_out {
-	remote-endpoint = <&retimer_ss2_ss_in>;
-};
-
-&usb_2_hsphy {
-	phys = <&eusb5_repeater>;
-
-	pinctrl-0 = <&wcn_usb_sw_n>;
-	pinctrl-names = "default";
-};
-
-&usb_mp_hsphy0 {
-	phys = <&eusb3_repeater>;
-};
-
-&usb_mp_hsphy1 {
-	phys = <&eusb6_repeater>;
-};
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "hamoa-iot-som.dtsi"
+#include "iq-x-iot-evk.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. Hamoa IoT EVK";
+	compatible = "qcom,hamoa-iot-evk",
+		     "qcom,hamoa-iot-som",
+		     "qcom,x1e80100";
+
+	usb-1-ss0-sbu-mux {
+		compatible = "onnn,fsusb42", "gpio-sbu-mux";
+
+		enable-gpios = <&tlmm 168 GPIO_ACTIVE_LOW>;
+		select-gpios = <&tlmm 167 GPIO_ACTIVE_HIGH>;
+
+		pinctrl-0 = <&usb_1_ss0_sbu_default>;
+		pinctrl-names = "default";
+
+		mode-switch;
+		orientation-switch;
+
+		port {
+			usb_1_ss0_sbu_mux: endpoint {
+				remote-endpoint = <&pmic_glink_ss0_sbu>;
+			};
+		};
+	};
+};
+
+
+&pmic_glink_port0 {
+	reg = <0>;
+	pmic_glink_ss0_hs_in: endpoint {
+		remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+	};
+};
+&pmic_glink_port1 {
+	reg = <1>;
+	pmic_glink_ss0_ss_in: endpoint {
+		remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+	};
+};
+&pmic_glink_port2 {
+	reg = <2>;
+	pmic_glink_ss0_sbu: endpoint {
+		remote-endpoint = <&usb_1_ss0_sbu_mux>;
+	};
+};
+
+&tlmm {
+	usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
+		mode-pins {
+			pins = "gpio166";
+			function = "gpio";
+			bias-disable;
+			drive-strength = <2>;
+			output-high;
+		};
+
+		oe-n-pins {
+			pins = "gpio168";
+			function = "gpio";
+			bias-disable;
+			drive-strength = <2>;
+		};
+
+		sel-pins {
+			pins = "gpio167";
+			function = "gpio";
+			bias-disable;
+			drive-strength = <2>;
+		};
+	};
+};
+
+
+&usb_1_ss0_qmpphy_out {
+	remote-endpoint = <&pmic_glink_ss0_ss_in>;
+};
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
dissimilarity index 98%
index 4a69852e9176..983b144047bc 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
@@ -1,618 +1,15 @@
-// SPDX-License-Identifier: BSD-3-Clause
-/*
- * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
- */
-
-#include "hamoa.dtsi"
-#include "hamoa-pmics.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
-
-/ {
-	reserved-memory {
-		linux,cma {
-			compatible = "shared-dma-pool";
-			size = <0x0 0x8000000>;
-			reusable;
-			linux,cma-default;
-		};
-	};
-};
-
-&apps_rsc {
-	/* PMC8380C_B */
-	regulators-0 {
-		compatible = "qcom,pm8550-rpmh-regulators";
-		qcom,pmic-id = "b";
-
-		vdd-bob1-supply = <&vph_pwr>;
-		vdd-bob2-supply = <&vph_pwr>;
-		vdd-l1-l4-l10-supply = <&vreg_s4c_1p8>;
-		vdd-l2-l13-l14-supply = <&vreg_bob1>;
-		vdd-l5-l16-supply = <&vreg_bob1>;
-		vdd-l6-l7-supply = <&vreg_bob2>;
-		vdd-l8-l9-supply = <&vreg_bob1>;
-		vdd-l12-supply = <&vreg_s5j_1p2>;
-		vdd-l15-supply = <&vreg_s4c_1p8>;
-		vdd-l17-supply = <&vreg_bob2>;
-
-		vreg_bob1: bob1 {
-			regulator-name = "vreg_bob1";
-			regulator-min-microvolt = <3008000>;
-			regulator-max-microvolt = <3960000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_bob2: bob2 {
-			regulator-name = "vreg_bob2";
-			regulator-min-microvolt = <2504000>;
-			regulator-max-microvolt = <3008000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l1b_1p8: ldo1 {
-			regulator-name = "vreg_l1b_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2b_3p0: ldo2 {
-			regulator-name = "vreg_l2b_3p0";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3100000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l4b_1p8: ldo4 {
-			regulator-name = "vreg_l4b_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l5b_3p0: ldo5 {
-			regulator-name = "vreg_l5b_3p0";
-			regulator-min-microvolt = <3000000>;
-			regulator-max-microvolt = <3000000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l6b_1p8: ldo6 {
-			regulator-name = "vreg_l6b_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <2960000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l7b_2p8: ldo7 {
-			regulator-name = "vreg_l7b_2p8";
-			regulator-min-microvolt = <2800000>;
-			regulator-max-microvolt = <2800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l8b_3p0: ldo8 {
-			regulator-name = "vreg_l8b_3p0";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3072000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l9b_2p9: ldo9 {
-			regulator-name = "vreg_l9b_2p9";
-			regulator-min-microvolt = <2960000>;
-			regulator-max-microvolt = <2960000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l10b_1p8: ldo10 {
-			regulator-name = "vreg_l10b_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l12b_1p2: ldo12 {
-			regulator-name = "vreg_l12b_1p2";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
-		};
-
-		vreg_l13b_3p0: ldo13 {
-			regulator-name = "vreg_l13b_3p0";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3100000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l14b_3p0: ldo14 {
-			regulator-name = "vreg_l14b_3p0";
-			regulator-min-microvolt = <3072000>;
-			regulator-max-microvolt = <3072000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l15b_1p8: ldo15 {
-			regulator-name = "vreg_l15b_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
-		};
-
-		vreg_l16b_2p9: ldo16 {
-			regulator-name = "vreg_l16b_2p9";
-			regulator-min-microvolt = <2912000>;
-			regulator-max-microvolt = <2912000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l17b_2p5: ldo17 {
-			regulator-name = "vreg_l17b_2p5";
-			regulator-min-microvolt = <2504000>;
-			regulator-max-microvolt = <2504000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380VE_C */
-	regulators-1 {
-		compatible = "qcom,pm8550ve-rpmh-regulators";
-		qcom,pmic-id = "c";
-
-		vdd-l1-supply = <&vreg_s5j_1p2>;
-		vdd-l2-supply = <&vreg_s1f_0p7>;
-		vdd-l3-supply = <&vreg_s1f_0p7>;
-		vdd-s4-supply = <&vph_pwr>;
-
-		vreg_s4c_1p8: smps4 {
-			regulator-name = "vreg_s4c_1p8";
-			regulator-min-microvolt = <1856000>;
-			regulator-max-microvolt = <2000000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l1c_1p2: ldo1 {
-			regulator-name = "vreg_l1c_1p2";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2c_0p8: ldo2 {
-			regulator-name = "vreg_l2c_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3c_0p8: ldo3 {
-			regulator-name = "vreg_l3c_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380_D */
-	regulators-2 {
-		compatible = "qcom,pmc8380-rpmh-regulators";
-		qcom,pmic-id = "d";
-
-		vdd-l1-supply = <&vreg_s1f_0p7>;
-		vdd-l2-supply = <&vreg_s1f_0p7>;
-		vdd-l3-supply = <&vreg_s4c_1p8>;
-		vdd-s1-supply = <&vph_pwr>;
-
-		vreg_l1d_0p8: ldo1 {
-			regulator-name = "vreg_l1d_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2d_0p9: ldo2 {
-			regulator-name = "vreg_l2d_0p9";
-			regulator-min-microvolt = <912000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3d_1p8: ldo3 {
-			regulator-name = "vreg_l3d_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380_E */
-	regulators-3 {
-		compatible = "qcom,pmc8380-rpmh-regulators";
-		qcom,pmic-id = "e";
-
-		vdd-l2-supply = <&vreg_s1f_0p7>;
-		vdd-l3-supply = <&vreg_s5j_1p2>;
-
-		vreg_l2e_0p8: ldo2 {
-			regulator-name = "vreg_l2e_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3e_1p2: ldo3 {
-			regulator-name = "vreg_l3e_1p2";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380_F */
-	regulators-4 {
-		compatible = "qcom,pmc8380-rpmh-regulators";
-		qcom,pmic-id = "f";
-
-		vdd-l1-supply = <&vreg_s5j_1p2>;
-		vdd-l2-supply = <&vreg_s5j_1p2>;
-		vdd-l3-supply = <&vreg_s5j_1p2>;
-		vdd-s1-supply = <&vph_pwr>;
-
-		vreg_s1f_0p7: smps1 {
-			regulator-name = "vreg_s1f_0p7";
-			regulator-min-microvolt = <700000>;
-			regulator-max-microvolt = <1100000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l1f_1p0: ldo1 {
-			regulator-name = "vreg_l1f_1p0";
-			regulator-min-microvolt = <1024000>;
-			regulator-max-microvolt = <1024000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2f_1p0: ldo2 {
-			regulator-name = "vreg_l2f_1p0";
-			regulator-min-microvolt = <1024000>;
-			regulator-max-microvolt = <1024000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3f_1p0: ldo3 {
-			regulator-name = "vreg_l3f_1p0";
-			regulator-min-microvolt = <1024000>;
-			regulator-max-microvolt = <1024000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380VE_I */
-	regulators-6 {
-		compatible = "qcom,pm8550ve-rpmh-regulators";
-		qcom,pmic-id = "i";
-
-		vdd-l1-supply = <&vreg_s4c_1p8>;
-		vdd-l2-supply = <&vreg_s5j_1p2>;
-		vdd-l3-supply = <&vreg_s1f_0p7>;
-		vdd-s1-supply = <&vph_pwr>;
-		vdd-s2-supply = <&vph_pwr>;
-
-		vreg_s1i_0p9: smps1 {
-			regulator-name = "vreg_s1i_0p9";
-			regulator-min-microvolt = <900000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_s2i_1p0: smps2 {
-			regulator-name = "vreg_s2i_1p0";
-			regulator-min-microvolt = <1000000>;
-			regulator-max-microvolt = <1100000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l1i_1p8: ldo1 {
-			regulator-name = "vreg_l1i_1p8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2i_1p2: ldo2 {
-			regulator-name = "vreg_l2i_1p2";
-			regulator-min-microvolt = <1200000>;
-			regulator-max-microvolt = <1200000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3i_0p8: ldo3 {
-			regulator-name = "vreg_l3i_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-
-	/* PMC8380VE_J */
-	regulators-7 {
-		compatible = "qcom,pm8550ve-rpmh-regulators";
-		qcom,pmic-id = "j";
-
-		vdd-l1-supply = <&vreg_s1f_0p7>;
-		vdd-l2-supply = <&vreg_s5j_1p2>;
-		vdd-l3-supply = <&vreg_s1f_0p7>;
-		vdd-s5-supply = <&vph_pwr>;
-
-		vreg_s5j_1p2: smps5 {
-			regulator-name = "vreg_s5j_1p2";
-			regulator-min-microvolt = <1256000>;
-			regulator-max-microvolt = <1304000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l1j_0p8: ldo1 {
-			regulator-name = "vreg_l1j_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l2j_1p2: ldo2 {
-			regulator-name = "vreg_l2j_1p2";
-			regulator-min-microvolt = <1256000>;
-			regulator-max-microvolt = <1256000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-
-		vreg_l3j_0p8: ldo3 {
-			regulator-name = "vreg_l3j_0p8";
-			regulator-min-microvolt = <880000>;
-			regulator-max-microvolt = <920000>;
-			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-		};
-	};
-};
-
-&iris {
-	status = "okay";
-};
-
-&gpu {
-	status = "okay";
-};
-
-&gpu_zap_shader {
-	firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
-};
-
-&pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
-	pinctrl-0 = <&pcie4_default>;
-	pinctrl-names = "default";
-
-	status = "okay";
-};
-
-&pcie4_phy {
-	vdda-phy-supply = <&vreg_l3i_0p8>;
-	vdda-pll-supply = <&vreg_l3e_1p2>;
-
-	status = "okay";
-};
-
-&pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
-	pinctrl-0 = <&pcie6a_default>;
-	pinctrl-names = "default";
-
-	status = "okay";
-};
-
-&pcie6a_phy {
-	vdda-phy-supply = <&vreg_l1d_0p8>;
-	vdda-pll-supply = <&vreg_l2j_1p2>;
-
-	status = "okay";
-};
-
-&qupv3_0 {
-	status = "okay";
-};
-
-&qupv3_1 {
-	status = "okay";
-};
-
-&qupv3_2 {
-	status = "okay";
-};
-
-&remoteproc_adsp {
-	firmware-name = "qcom/x1e80100/adsp.mbn",
-			"qcom/x1e80100/adsp_dtb.mbn";
-
-	status = "okay";
-};
-
-&remoteproc_cdsp {
-	firmware-name = "qcom/x1e80100/cdsp.mbn",
-			"qcom/x1e80100/cdsp_dtb.mbn";
-
-	status = "okay";
-};
-
-&tlmm {
-	gpio-reserved-ranges = <34 2>; /* TPM LP & INT */
-
-	pcie4_default: pcie4-default-state {
-		clkreq-n-pins {
-			pins = "gpio147";
-			function = "pcie4_clk";
-			drive-strength = <2>;
-			bias-pull-up;
-		};
-
-		perst-n-pins {
-			pins = "gpio146";
-			function = "gpio";
-			drive-strength = <2>;
-			bias-disable;
-		};
-
-		wake-n-pins {
-			pins = "gpio148";
-			function = "gpio";
-			drive-strength = <2>;
-			bias-pull-up;
-		};
-	};
-
-	pcie6a_default: pcie6a-default-state {
-		clkreq-n-pins {
-			pins = "gpio153";
-			function = "pcie6a_clk";
-			drive-strength = <2>;
-			bias-pull-up;
-		};
-
-		perst-n-pins {
-			pins = "gpio152";
-			function = "gpio";
-			drive-strength = <2>;
-			bias-disable;
-		};
-
-		wake-n-pins {
-			pins = "gpio154";
-			function = "gpio";
-			drive-strength = <2>;
-			bias-pull-up;
-
-		};
-	};
-};
-
-&usb_1_ss0 {
-	status = "okay";
-};
-
-&usb_1_ss0_dwc3 {
-	dr_mode = "otg";
-	usb-role-switch;
-};
-
-&usb_1_ss0_hsphy {
-	vdd-supply = <&vreg_l3j_0p8>;
-	vdda12-supply = <&vreg_l2j_1p2>;
-
-	status = "okay";
-};
-
-&usb_1_ss0_qmpphy {
-	vdda-phy-supply = <&vreg_l2j_1p2>;
-	vdda-pll-supply = <&vreg_l1j_0p8>;
-
-	status = "okay";
-};
-
-&usb_1_ss1 {
-	status = "okay";
-};
-
-&usb_1_ss1_dwc3 {
-	dr_mode = "otg";
-	usb-role-switch;
-};
-
-&usb_1_ss1_hsphy {
-	vdd-supply = <&vreg_l3j_0p8>;
-	vdda12-supply = <&vreg_l2j_1p2>;
-
-	status = "okay";
-};
-
-&usb_1_ss1_qmpphy {
-	vdda-phy-supply = <&vreg_l2j_1p2>;
-	vdda-pll-supply = <&vreg_l2d_0p9>;
-
-	status = "okay";
-};
-
-&usb_1_ss2 {
-	status = "okay";
-};
-
-&usb_1_ss2_dwc3 {
-	dr_mode = "otg";
-	usb-role-switch;
-};
-
-&usb_1_ss2_hsphy {
-	vdd-supply = <&vreg_l3j_0p8>;
-	vdda12-supply = <&vreg_l2j_1p2>;
-
-	status = "okay";
-};
-
-&usb_1_ss2_qmpphy {
-	vdda-phy-supply = <&vreg_l2j_1p2>;
-	vdda-pll-supply = <&vreg_l2d_0p9>;
-
-	status = "okay";
-};
-
-&usb_2 {
-	status = "okay";
-};
-
-&usb_2_dwc3 {
-	dr_mode = "host";
-};
-
-&usb_2_hsphy {
-	vdd-supply = <&vreg_l2e_0p8>;
-	vdda12-supply = <&vreg_l3e_1p2>;
-
-	status = "okay";
-};
-
-&usb_mp {
-	status = "okay";
-};
-
-&usb_mp_hsphy0 {
-	vdd-supply = <&vreg_l2e_0p8>;
-	vdda12-supply = <&vreg_l3e_1p2>;
-
-	status = "okay";
-};
-
-&usb_mp_hsphy1 {
-	vdd-supply = <&vreg_l2e_0p8>;
-	vdda12-supply = <&vreg_l3e_1p2>;
-
-	status = "okay";
-};
-
-&usb_mp_qmpphy0 {
-	vdda-phy-supply = <&vreg_l3e_1p2>;
-	vdda-pll-supply = <&vreg_l3c_0p8>;
-
-	status = "okay";
-};
-
-&usb_mp_qmpphy1 {
-	vdda-phy-supply = <&vreg_l3e_1p2>;
-	vdda-pll-supply = <&vreg_l3c_0p8>;
-
-	status = "okay";
-};
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include "hamoa.dtsi"
+#include "iq-x-iot-som.dtsi"
+
+&gpu_zap_shader {
+	firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
+};
+
+&iris {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/iq-x-iot-evk.dtsi
similarity index 94%
copy from arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
copy to arch/arm64/boot/dts/qcom/iq-x-iot-evk.dtsi
index 36dd6599402b..7d6dbe9a0885 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/iq-x-iot-evk.dtsi
@@ -3,13 +3,7 @@
  * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
-/dts-v1/;
-
-#include "hamoa-iot-som.dtsi"
-
 / {
-	model = "Qualcomm Technologies, Inc. Hamoa IoT EVK";
-	compatible = "qcom,hamoa-iot-evk", "qcom,hamoa-iot-som", "qcom,x1e80100";
 	chassis-type = "embedded";
 
 	aliases {
@@ -68,28 +62,13 @@ ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				port@0 {
-					reg = <0>;
-
-					pmic_glink_ss0_hs_in: endpoint {
-						remote-endpoint = <&usb_1_ss0_dwc3_hs>;
-					};
+				pmic_glink_port0: port@0 {
 				};
 
-				port@1 {
-					reg = <1>;
-
-					pmic_glink_ss0_ss_in: endpoint {
-						remote-endpoint = <&usb_1_ss0_qmpphy_out>;
-					};
+				pmic_glink_port1: port@1 {
 				};
 
-				port@2 {
-					reg = <2>;
-
-					pmic_glink_ss0_sbu: endpoint {
-						remote-endpoint = <&usb_1_ss0_sbu_mux>;
-					};
+				pmic_glink_port2: port@2 {
 				};
 			};
 		};
@@ -502,25 +481,6 @@ platform {
 		};
 	};
 
-	usb-1-ss0-sbu-mux {
-		compatible = "onnn,fsusb42", "gpio-sbu-mux";
-
-		enable-gpios = <&tlmm 168 GPIO_ACTIVE_LOW>;
-		select-gpios = <&tlmm 167 GPIO_ACTIVE_HIGH>;
-
-		pinctrl-0 = <&usb_1_ss0_sbu_default>;
-		pinctrl-names = "default";
-
-		mode-switch;
-		orientation-switch;
-
-		port {
-			usb_1_ss0_sbu_mux: endpoint {
-				remote-endpoint = <&pmic_glink_ss0_sbu>;
-			};
-		};
-	};
-
 	wcn7850-pmu {
 		compatible = "qcom,wcn7850-pmu";
 
@@ -1104,30 +1064,6 @@ usb2_pwr_3p3_reg_en: usb2-pwr-3p3-reg-en-state {
 		bias-disable;
 	};
 
-	usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
-		mode-pins {
-			pins = "gpio166";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-			output-high;
-		};
-
-		oe-n-pins {
-			pins = "gpio168";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-		};
-
-		sel-pins {
-			pins = "gpio167";
-			function = "gpio";
-			bias-disable;
-			drive-strength = <2>;
-		};
-	};
-
 	wcd_default: wcd-reset-n-active-state {
 		pins = "gpio191";
 		function = "gpio";
@@ -1198,10 +1134,6 @@ &usb_1_ss0_hsphy {
 	phys = <&smb2360_0_eusb2_repeater>;
 };
 
-&usb_1_ss0_qmpphy_out {
-	remote-endpoint = <&pmic_glink_ss0_ss_in>;
-};
-
 &usb_1_ss1_dwc3_hs {
 	remote-endpoint = <&pmic_glink_ss1_hs_in>;
 };
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/iq-x-iot-som.dtsi
similarity index 99%
copy from arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
copy to arch/arm64/boot/dts/qcom/iq-x-iot-som.dtsi
index 4a69852e9176..051df8ecaf94 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/iq-x-iot-som.dtsi
@@ -3,7 +3,6 @@
  * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
-#include "hamoa.dtsi"
 #include "hamoa-pmics.dtsi"
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -378,18 +377,10 @@ vreg_l3j_0p8: ldo3 {
 	};
 };
 
-&iris {
-	status = "okay";
-};
-
 &gpu {
 	status = "okay";
 };
 
-&gpu_zap_shader {
-	firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
-};
-
 &pcie4 {
 	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
 	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-- 
2.34.1

[PATCH 4/4] arm64: dts: qcom: Add base PURWA-IOT-EVK board

[YijieYang]

From: Yijie Yang <yijie.yang@oss.qualcomm.com>

The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of
the Purwa IoT SoM and a carrier board. Together, they form a complete
embedded system capable of booting to UART.

PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK.
Meanwhile, USB0 bypasses the SBU selector FSUSB42. As a result, the glink
topology differs from that of HAMOA-IOT-EVK.

Make the following peripherals on the carrier board enabled:
- UART
- On-board regulators
- Regulators on the SOM
- PMIC GLINK
- USB0 through USB6 and their PHYs
- Embedded USB (EUSB) repeaters
- USB Type-C mux
- PCIe6a and its PHY
- PCIe4 and its PHY
- Reserved memory regions
- Pinctrl
- NVMe
- ADSP, CDSP
- WLAN, Bluetooth (M.2 interface)
- USB DisplayPorts
- Graphic
- Audio

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile           |   1 +
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts  | 100 ++++++++++++++++++++
 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi |  11 +++
 3 files changed, 112 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
 create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f34d5ed331c..803a525093e7 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -123,6 +123,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-lilac.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-maple.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-sony-xperia-yoshino-poplar.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-xiaomi-sagit.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= purwa-iot-evk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-fairphone-fp5.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcm6490-particle-tachyon.dtb
diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
new file mode 100644
index 000000000000..95cfb7024751
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "purwa-iot-som.dtsi"
+#include "iq-x-iot-evk.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. Purwa IoT EVK";
+	compatible = "qcom,purwa-iot-evk",
+		     "qcom,purwa-iot-som",
+		     "qcom,x1p42100";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&pmic_glink_port0 {
+	reg = <0>;
+	pmic_glink_ss0_hs_in: endpoint {
+		remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+	};
+};
+&pmic_glink_port1 {
+	reg = <1>;
+	pmic_glink_ss0_ss_in: endpoint {
+		remote-endpoint = <&retimer_ss0_ss_out>;
+	};
+};
+&pmic_glink_port2 {
+	reg = <2>;
+	pmic_glink_ss0_con_sbu_in: endpoint {
+		remote-endpoint = <&retimer_ss0_con_sbu_out>;
+	};
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+
+	status = "okay";
+
+	typec-mux@8 {
+		compatible = "parade,ps8830";
+		reg = <0x8>;
+
+		clocks = <&rpmhcc RPMH_RF_CLK4>;
+
+		vdd-supply = <&vreg_rtmr0_1p15>;
+		vdd33-supply = <&vreg_rtmr0_3p3>;
+		vdd33-cap-supply = <&vreg_rtmr0_3p3>;
+		vddar-supply = <&vreg_rtmr0_1p15>;
+		vddat-supply = <&vreg_rtmr0_1p15>;
+		vddio-supply = <&vreg_rtmr0_1p8>;
+
+		reset-gpios = <&pm8550_gpios 10 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&rtmr0_default>;
+		pinctrl-names = "default";
+
+		retimer-switch;
+		orientation-switch;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				retimer_ss0_ss_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_ss_in>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				retimer_ss0_ss_in: endpoint {
+					remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+
+				retimer_ss0_con_sbu_out: endpoint {
+					remote-endpoint = <&pmic_glink_ss0_con_sbu_in>;
+				};
+			};
+		};
+	};
+};
+
+&usb_1_ss0_qmpphy_out {
+	remote-endpoint = <&retimer_ss0_ss_in>;
+};
diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
new file mode 100644
index 000000000000..1ee7478d7614
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include "purwa.dtsi"
+#include "iq-x-iot-som.dtsi"
+
+&gpu_zap_shader {
+	firmware-name = "qcom/x1e80100/gen71500_zap.mbn";
+};
-- 
2.34.1

Re: [PATCH 2/4] dt-bindings: arm: qcom: Document PURWA-IOT-EVK board

[Krzysztof Kozlowski]

On Mon, Dec 22, 2025 at 02:03:27PM +0800, YijieYang wrote:
> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> Document the device tree bindings for the PURWA-IOT-EVK board, which
> uses the Qualcomm X1P42100 SoC. Split the common parts of the SoM and
> carrier boards for HAMOA and PURWA into separate files for better
> modularity.
> 
> Introduce the IQ-X-IOT series here, as both HAMOA and PURWA belong to
> Qualcomm’s IQ-X family. For more details on IQ-X series, see:
> https://www.qualcomm.com/internet-of-things/products/iq-x-series
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH 1/4] firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK

[Krzysztof Kozlowski]

On Mon, Dec 22, 2025 at 02:03:26PM +0800, YijieYang wrote:
> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> Add the Purwa-IoT-EVK board to the list to enable access to EFI variables.
> 
> Guarantee that subsystems relying on SCM services can access secure-world
> features. This change improves reliability and prevents missing functionality
> or boot-time issues by making service availability explicit.
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 1a6f85e463e0..1fed7a81bd29 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2010,6 +2010,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
>  	{ .compatible = "microsoft,romulus13", },
>  	{ .compatible = "microsoft,romulus15", },
>  	{ .compatible = "qcom,hamoa-iot-evk" },
> +	{ .compatible = "qcom,purwa-iot-evk" },

Why are you using ABI before documenting the ABI?

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
> the common components into separate files for better maintainability.

SoMs do not share actual hardware. DTSI does not represent what looks
similar to you, but actually common parts.

Best regards,
Krzysztof

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Dmitry Baryshkov]

On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> Introduce the device tree, DT bindings, and driver modifications required
> to bring up the PURWA-IOT-EVK evaluation board.
> 
> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
> the IQ-X SoC series. Consequently, the two common files in this series are
> prefixed with 'iq-x-iot' to reflect this relationship.
> 
> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
> except for differences in the BOM. As a result, most of the DTS can be
> shared between them.
> 
> The changes focus on two key hardware components: the PURWA-IOT-SOM and
> the PURWA-IOT-EVK carrier board.
> 
> Hardware delta between Hamoa and Purwa:
> - Display: Purwa’s display uses a different number of clocks, and its
>   frequency differs from Hamoa.
> - GPU: Purwa requires a separate firmware compared to Hamoa.

Is it just a separate firmware, or does it use a different _GPU_?

> - USB0: Purwa uses a PS8833 retimer, while Hamoa uses an FSUSB42 as the
>   SBU switch.
> 

-- 
With best wishes
Dmitry

Re: [PATCH 4/4] arm64: dts: qcom: Add base PURWA-IOT-EVK board

[Dmitry Baryshkov]

On Mon, Dec 22, 2025 at 02:03:29PM +0800, YijieYang wrote:
> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of
> the Purwa IoT SoM and a carrier board. Together, they form a complete
> embedded system capable of booting to UART.
> 
> PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK.
> Meanwhile, USB0 bypasses the SBU selector FSUSB42. As a result, the glink
> topology differs from that of HAMOA-IOT-EVK.
> 
> Make the following peripherals on the carrier board enabled:
> - UART
> - On-board regulators
> - Regulators on the SOM
> - PMIC GLINK
> - USB0 through USB6 and their PHYs
> - Embedded USB (EUSB) repeaters
> - USB Type-C mux
> - PCIe6a and its PHY
> - PCIe4 and its PHY
> - Reserved memory regions
> - Pinctrl
> - NVMe
> - ADSP, CDSP
> - WLAN, Bluetooth (M.2 interface)
> - USB DisplayPorts
> - Graphic
> - Audio
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile           |   1 +
>  arch/arm64/boot/dts/qcom/purwa-iot-evk.dts  | 100 ++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi |  11 +++
>  3 files changed, 112 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> 

> +
> +&gpu_zap_shader {
> +	firmware-name = "qcom/x1e80100/gen71500_zap.mbn";

This wasn't tested.

> +};
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/4] firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK

[Yijie Yang]

On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> On Mon, Dec 22, 2025 at 02:03:26PM +0800, YijieYang wrote:
>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>
>> Add the Purwa-IoT-EVK board to the list to enable access to EFI variables.
>>
>> Guarantee that subsystems relying on SCM services can access secure-world
>> features. This change improves reliability and prevents missing functionality
>> or boot-time issues by making service availability explicit.
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   drivers/firmware/qcom/qcom_scm.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
>> index 1a6f85e463e0..1fed7a81bd29 100644
>> --- a/drivers/firmware/qcom/qcom_scm.c
>> +++ b/drivers/firmware/qcom/qcom_scm.c
>> @@ -2010,6 +2010,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
>>   	{ .compatible = "microsoft,romulus13", },
>>   	{ .compatible = "microsoft,romulus15", },
>>   	{ .compatible = "qcom,hamoa-iot-evk" },
>> +	{ .compatible = "qcom,purwa-iot-evk" },
> 
> Why are you using ABI before documenting the ABI?

I’ll reorder the patch sequence.

> 
> Best regards,
> Krzysztof
> 

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Yijie Yang]

On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>
>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>> the common components into separate files for better maintainability.
> 
> SoMs do not share actual hardware. DTSI does not represent what looks
> similar to you, but actually common parts.

The two SOMs share the same hardware except for the SoC. What are your 
suggestions for the file architecture?

> 
> Best regards,
> Krzysztof
> 

-- 
Best Regards,
Yijie

Re: [PATCH 4/4] arm64: dts: qcom: Add base PURWA-IOT-EVK board

[Yijie Yang]

On 12/22/2025 5:22 PM, Dmitry Baryshkov wrote:
> On Mon, Dec 22, 2025 at 02:03:29PM +0800, YijieYang wrote:
>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>
>> The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of
>> the Purwa IoT SoM and a carrier board. Together, they form a complete
>> embedded system capable of booting to UART.
>>
>> PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK.
>> Meanwhile, USB0 bypasses the SBU selector FSUSB42. As a result, the glink
>> topology differs from that of HAMOA-IOT-EVK.
>>
>> Make the following peripherals on the carrier board enabled:
>> - UART
>> - On-board regulators
>> - Regulators on the SOM
>> - PMIC GLINK
>> - USB0 through USB6 and their PHYs
>> - Embedded USB (EUSB) repeaters
>> - USB Type-C mux
>> - PCIe6a and its PHY
>> - PCIe4 and its PHY
>> - Reserved memory regions
>> - Pinctrl
>> - NVMe
>> - ADSP, CDSP
>> - WLAN, Bluetooth (M.2 interface)
>> - USB DisplayPorts
>> - Graphic
>> - Audio
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile           |   1 +
>>   arch/arm64/boot/dts/qcom/purwa-iot-evk.dts  | 100 ++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi |  11 +++
>>   3 files changed, 112 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
>>   create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
>>
> 
>> +
>> +&gpu_zap_shader {
>> +	firmware-name = "qcom/x1e80100/gen71500_zap.mbn";
> 
> This wasn't tested.

It should be qcom/x1p42100/gen71500_zap.mbn. This has been tested locally.

> 
>> +};
>> -- 
>> 2.34.1
>>
> 

-- 
Best Regards,
Yijie

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Yijie Yang]

On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>
>> Introduce the device tree, DT bindings, and driver modifications required
>> to bring up the PURWA-IOT-EVK evaluation board.
>>
>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>> the IQ-X SoC series. Consequently, the two common files in this series are
>> prefixed with 'iq-x-iot' to reflect this relationship.
>>
>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>> except for differences in the BOM. As a result, most of the DTS can be
>> shared between them.
>>
>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>> the PURWA-IOT-EVK carrier board.
>>
>> Hardware delta between Hamoa and Purwa:
>> - Display: Purwa’s display uses a different number of clocks, and its
>>    frequency differs from Hamoa.
>> - GPU: Purwa requires a separate firmware compared to Hamoa.
> 
> Is it just a separate firmware, or does it use a different _GPU_?

It uses a different GPU.

> 
>> - USB0: Purwa uses a PS8833 retimer, while Hamoa uses an FSUSB42 as the
>>    SBU switch.
>>
> 

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>
>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>> the common components into separate files for better maintainability.
> SoMs do not share actual hardware. DTSI does not represent what looks
> similar to you, but actually common parts.
Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
has Hamoa on it. 
> Best regards,
> Krzysztof
>
>

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 23/12/2025 04:38, Tingwei Zhang wrote:
> 
> 
> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>
>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>> the common components into separate files for better maintainability.
>> SoMs do not share actual hardware. DTSI does not represent what looks
>> similar to you, but actually common parts.
> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
> has Hamoa on it. 

I do not speak about boards. Read carefully feedback and respond to the
actual feedback, not some other arguments.

NAK

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 23/12/2025 03:00, Yijie Yang wrote:
> 
> 
> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>
>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>> the common components into separate files for better maintainability.
>>
>> SoMs do not share actual hardware. DTSI does not represent what looks
>> similar to you, but actually common parts.
> 
> The two SOMs share the same hardware except for the SoC. What are your 
> suggestions for the file architecture?

Not likely. That's like saying SM8650 and SM8550 share the same
hardware... Take the Som to your hand. Can you remove the soc? No? So
you're done. Separate device.

Best regards,
Krzysztof

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Konrad Dybcio]

On 12/23/25 3:12 AM, Yijie Yang wrote:
> 
> 
> On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
>> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>
>>> Introduce the device tree, DT bindings, and driver modifications required
>>> to bring up the PURWA-IOT-EVK evaluation board.
>>>
>>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>>> the IQ-X SoC series. Consequently, the two common files in this series are
>>> prefixed with 'iq-x-iot' to reflect this relationship.
>>>
>>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>>> except for differences in the BOM. As a result, most of the DTS can be
>>> shared between them.
>>>
>>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>>> the PURWA-IOT-EVK carrier board.
>>>
>>> Hardware delta between Hamoa and Purwa:
>>> - Display: Purwa’s display uses a different number of clocks, and its
>>>    frequency differs from Hamoa.
>>> - GPU: Purwa requires a separate firmware compared to Hamoa.
>>
>> Is it just a separate firmware, or does it use a different _GPU_?
> 
> It uses a different GPU.

I think it would be useful to call this paragraph "Hardware delta between
Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
about differences between Hamoa-the-SoC and Purwa-the-SoC which we
expressed in purwa.dtsi

Konrad

> 
>>
>>> - USB0: Purwa uses a PS8833 retimer, while Hamoa uses an FSUSB42 as the
>>>    SBU switch.
>>>
>>
> 

Re: [PATCH 4/4] arm64: dts: qcom: Add base PURWA-IOT-EVK board

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 10:02:54AM +0800, Yijie Yang wrote:
> 
> 
> On 12/22/2025 5:22 PM, Dmitry Baryshkov wrote:
> > On Mon, Dec 22, 2025 at 02:03:29PM +0800, YijieYang wrote:
> > > From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > 
> > > The PURWA-IOT-EVK is an evaluation platform for IoT products, composed of
> > > the Purwa IoT SoM and a carrier board. Together, they form a complete
> > > embedded system capable of booting to UART.
> > > 
> > > PURWA-IOT-EVK uses the PS8833 as a retimer for USB0, unlike HAMOA-IOT-EVK.
> > > Meanwhile, USB0 bypasses the SBU selector FSUSB42. As a result, the glink
> > > topology differs from that of HAMOA-IOT-EVK.
> > > 
> > > Make the following peripherals on the carrier board enabled:
> > > - UART
> > > - On-board regulators
> > > - Regulators on the SOM
> > > - PMIC GLINK
> > > - USB0 through USB6 and their PHYs
> > > - Embedded USB (EUSB) repeaters
> > > - USB Type-C mux
> > > - PCIe6a and its PHY
> > > - PCIe4 and its PHY
> > > - Reserved memory regions
> > > - Pinctrl
> > > - NVMe
> > > - ADSP, CDSP
> > > - WLAN, Bluetooth (M.2 interface)
> > > - USB DisplayPorts
> > > - Graphic
> > > - Audio
> > > 
> > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/Makefile           |   1 +
> > >   arch/arm64/boot/dts/qcom/purwa-iot-evk.dts  | 100 ++++++++++++++++++++
> > >   arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi |  11 +++
> > >   3 files changed, 112 insertions(+)
> > >   create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> > >   create mode 100644 arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > > 
> > 
> > > +
> > > +&gpu_zap_shader {
> > > +	firmware-name = "qcom/x1e80100/gen71500_zap.mbn";
> > 
> > This wasn't tested.
> 
> It should be qcom/x1p42100/gen71500_zap.mbn. This has been tested locally.

The DT that you've sent wasn't tested. Please send a fixed version.

> 
> > 
> > > +};
> > > -- 
> > > 2.34.1
> > > 
> > 
> 
> -- 
> Best Regards,
> Yijie
> 

-- 
With best wishes
Dmitry

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Dmitry Baryshkov]

On Tue, Dec 23, 2025 at 06:27:05PM +0100, Konrad Dybcio wrote:
> On 12/23/25 3:12 AM, Yijie Yang wrote:
> > 
> > 
> > On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
> >> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
> >>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> >>>
> >>> Introduce the device tree, DT bindings, and driver modifications required
> >>> to bring up the PURWA-IOT-EVK evaluation board.
> >>>
> >>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
> >>> the IQ-X SoC series. Consequently, the two common files in this series are
> >>> prefixed with 'iq-x-iot' to reflect this relationship.
> >>>
> >>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
> >>> except for differences in the BOM. As a result, most of the DTS can be
> >>> shared between them.
> >>>
> >>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
> >>> the PURWA-IOT-EVK carrier board.
> >>>
> >>> Hardware delta between Hamoa and Purwa:
> >>> - Display: Purwa’s display uses a different number of clocks, and its
> >>>    frequency differs from Hamoa.
> >>> - GPU: Purwa requires a separate firmware compared to Hamoa.
> >>
> >> Is it just a separate firmware, or does it use a different _GPU_?
> > 
> > It uses a different GPU.
> 
> I think it would be useful to call this paragraph "Hardware delta between
> Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
> about differences between Hamoa-the-SoC and Purwa-the-SoC which we
> expressed in purwa.dtsi

Nah, I pointed out that the letter is incorrect. It's not just a
different firmware for the _same_ GPU. It's a different GPU revision.

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>
>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>
>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>> the common components into separate files for better maintainability.
>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>> similar to you, but actually common parts.
>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>> has Hamoa on it. 
> I do not speak about boards. Read carefully feedback and respond to the
> actual feedback, not some other arguments.
>
> NAK
In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
> Best regards,
> Krzysztof

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Yijie Yang]

On 12/24/2025 1:27 AM, Konrad Dybcio wrote:
> On 12/23/25 3:12 AM, Yijie Yang wrote:
>>
>>
>> On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
>>> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>
>>>> Introduce the device tree, DT bindings, and driver modifications required
>>>> to bring up the PURWA-IOT-EVK evaluation board.
>>>>
>>>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>>>> the IQ-X SoC series. Consequently, the two common files in this series are
>>>> prefixed with 'iq-x-iot' to reflect this relationship.
>>>>
>>>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>>>> except for differences in the BOM. As a result, most of the DTS can be
>>>> shared between them.
>>>>
>>>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>>>> the PURWA-IOT-EVK carrier board.
>>>>
>>>> Hardware delta between Hamoa and Purwa:
>>>> - Display: Purwa’s display uses a different number of clocks, and its
>>>>     frequency differs from Hamoa.
>>>> - GPU: Purwa requires a separate firmware compared to Hamoa.
>>>
>>> Is it just a separate firmware, or does it use a different _GPU_?
>>
>> It uses a different GPU.
> 
> I think it would be useful to call this paragraph "Hardware delta between
> Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
> about differences between Hamoa-the-SoC and Purwa-the-SoC which we
> expressed in purwa.dtsi

I want to provide readers with a comprehensive comparison of the two 
boards, Hamoa-IoT-EVK and Purwa-IoT-EVK, covering all differences in 
both the SOM and the carrier board.

> 
> Konrad
> 
>>
>>>
>>>> - USB0: Purwa uses a PS8833 retimer, while Hamoa uses an FSUSB42 as the
>>>>     SBU switch.
>>>>
>>>
>>

-- 
Best Regards,
Yijie

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Yijie Yang]

On 12/24/2025 3:09 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 23, 2025 at 06:27:05PM +0100, Konrad Dybcio wrote:
>> On 12/23/25 3:12 AM, Yijie Yang wrote:
>>>
>>>
>>> On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
>>>> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>
>>>>> Introduce the device tree, DT bindings, and driver modifications required
>>>>> to bring up the PURWA-IOT-EVK evaluation board.
>>>>>
>>>>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>>>>> the IQ-X SoC series. Consequently, the two common files in this series are
>>>>> prefixed with 'iq-x-iot' to reflect this relationship.
>>>>>
>>>>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>>>>> except for differences in the BOM. As a result, most of the DTS can be
>>>>> shared between them.
>>>>>
>>>>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>>>>> the PURWA-IOT-EVK carrier board.
>>>>>
>>>>> Hardware delta between Hamoa and Purwa:
>>>>> - Display: Purwa’s display uses a different number of clocks, and its
>>>>>     frequency differs from Hamoa.
>>>>> - GPU: Purwa requires a separate firmware compared to Hamoa.
>>>>
>>>> Is it just a separate firmware, or does it use a different _GPU_?
>>>
>>> It uses a different GPU.
>>
>> I think it would be useful to call this paragraph "Hardware delta between
>> Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
>> about differences between Hamoa-the-SoC and Purwa-the-SoC which we
>> expressed in purwa.dtsi
> 
> Nah, I pointed out that the letter is incorrect. It's not just a
> different firmware for the _same_ GPU. It's a different GPU revision.

I’ll update the description here.

> 

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Yijie Yang]

On 12/23/2025 9:42 PM, Krzysztof Kozlowski wrote:
> On 23/12/2025 03:00, Yijie Yang wrote:
>>
>>
>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>
>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>> the common components into separate files for better maintainability.
>>>
>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>> similar to you, but actually common parts.
>>
>> The two SOMs share the same hardware except for the SoC. What are your
>> suggestions for the file architecture?
> 
> Not likely. That's like saying SM8650 and SM8550 share the same
> hardware... Take the Som to your hand. Can you remove the soc? No? So
> you're done. Separate device.

Although the two SOMs differ, they share an almost identical hardware 
layout. In this scenario, would there be any issue with extracting the 
common DTS parts into a separate file?

> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>
> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>
>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>> the common components into separate files for better maintainability.
>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>> similar to you, but actually common parts.
>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>> has Hamoa on it. 
>> I do not speak about boards. Read carefully feedback and respond to the
>> actual feedback, not some other arguments.
>>
>> NAK
> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
Krzysztof,
Please let me know your opinion on this. This could be a common case for
Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
would reduce maintenance effort.
>> Best regards,
>> Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 29/12/2025 02:23, Tingwei Zhang wrote:
> 
> 
> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>
>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>
>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>> the common components into separate files for better maintainability.
>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>> similar to you, but actually common parts.
>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>> has Hamoa on it. 
>>> I do not speak about boards. Read carefully feedback and respond to the
>>> actual feedback, not some other arguments.
>>>
>>> NAK
>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
> Krzysztof,
> Please let me know your opinion on this. This could be a common case for
> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi

It's not the same PCB.  You did not really respond to my first message,
so I responded to you - I do not speak about boards. Then again you did
not respond to it and brought some irrelevant arguments.

> would reduce maintenance effort.

Does not matter, I do not question this. Why are you responding to some
questions which were never asked?

DTSI represents actual shared physical aspect and you cannot share SoM
physically. It's not the same PCB, because you do not have a socket on
the SoM.

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Yijie Yang]

On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>
>>
>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>
>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>
>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>> the common components into separate files for better maintainability.
>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>> similar to you, but actually common parts.
>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>> has Hamoa on it.
>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>> actual feedback, not some other arguments.
>>>>
>>>> NAK
>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>> Krzysztof,
>> Please let me know your opinion on this. This could be a common case for
>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
> 
> It's not the same PCB.  You did not really respond to my first message,
> so I responded to you - I do not speak about boards. Then again you did
> not respond to it and brought some irrelevant arguments.
> 
>> would reduce maintenance effort.
> 
> Does not matter, I do not question this. Why are you responding to some
> questions which were never asked?
> 
> DTSI represents actual shared physical aspect and you cannot share SoM
> physically. It's not the same PCB, because you do not have a socket on
> the SoM.

x1e80100-crd and x1p42100-crd are different boards, yet they share the 
same x1-crd.dtsi. Why can’t we apply the same approach here?

> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 29/12/2025 08:38, Yijie Yang wrote:
> 
> 
> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>
>>>
>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>
>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>
>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>> the common components into separate files for better maintainability.
>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>> similar to you, but actually common parts.
>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>> has Hamoa on it.
>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>> actual feedback, not some other arguments.
>>>>>
>>>>> NAK
>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>> Krzysztof,
>>> Please let me know your opinion on this. This could be a common case for
>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>
>> It's not the same PCB.  You did not really respond to my first message,
>> so I responded to you - I do not speak about boards. Then again you did
>> not respond to it and brought some irrelevant arguments.
>>
>>> would reduce maintenance effort.
>>
>> Does not matter, I do not question this. Why are you responding to some
>> questions which were never asked?
>>
>> DTSI represents actual shared physical aspect and you cannot share SoM
>> physically. It's not the same PCB, because you do not have a socket on
>> the SoM.
> 
> x1e80100-crd and x1p42100-crd are different boards, yet they share the 
> same x1-crd.dtsi. Why can’t we apply the same approach here?


You should ask the authors there, not me. I presume that the baseboard
is the same or very similar. Or pieces of the baseboard are re-used
which could be visible in the schematics (same MCN numbers etc).

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>
>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>
>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>> the common components into separate files for better maintainability.
>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>> similar to you, but actually common parts.
>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>> has Hamoa on it. 
>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>> actual feedback, not some other arguments.
>>>>
>>>> NAK
>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>> Krzysztof,
>> Please let me know your opinion on this. This could be a common case for
>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
> It's not the same PCB.  You did not really respond to my first message,
> so I responded to you - I do not speak about boards. Then again you did
> not respond to it and brought some irrelevant arguments.
>
>> would reduce maintenance effort.
> Does not matter, I do not question this. Why are you responding to some
> questions which were never asked?
>
> DTSI represents actual shared physical aspect and you cannot share SoM
> physically. It's not the same PCB, because you do not have a socket on
> the SoM.
I didn't make myself clear enough. The SOM PCB I referred here is just the circuit
board excluding the components on it.  Let me rephrase.

Hamoa and Purwa SOM boards have very similar hardware design. They share
same circuit board and most the components on it. The only difference is Hamoa
SOM board has Hamoa SoC while Purwa SOM board has Purwa SoC.

I agree they are not same PCB since the SoCs are different. 

However, I still think it's better to use common dtsi iq-x-iot-som.dtsi since their
hardware design is very similar. 

I'll invite Konrad to chime in here as author of x1-crd.dtsi and Qualcomm SoC
maintainer. I think we are facing similar case on purwa evk and purwa crd.
Align to same strategy for device tree topology would be good.

> Best regards,
> Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Konrad Dybcio]

On 12/29/25 11:19 AM, Tingwei Zhang wrote:
> 
> 
> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>
>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>
>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>> the common components into separate files for better maintainability.
>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>> similar to you, but actually common parts.
>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>> has Hamoa on it. 
>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>> actual feedback, not some other arguments.
>>>>>
>>>>> NAK
>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>> Krzysztof,
>>> Please let me know your opinion on this. This could be a common case for
>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>> It's not the same PCB.  You did not really respond to my first message,
>> so I responded to you - I do not speak about boards. Then again you did
>> not respond to it and brought some irrelevant arguments.
>>
>>> would reduce maintenance effort.
>> Does not matter, I do not question this. Why are you responding to some
>> questions which were never asked?
>>
>> DTSI represents actual shared physical aspect and you cannot share SoM
>> physically. It's not the same PCB, because you do not have a socket on
>> the SoM.
> I didn't make myself clear enough. The SOM PCB I referred here is just the circuit
> board excluding the components on it.  Let me rephrase.
> 
> Hamoa and Purwa SOM boards have very similar hardware design. They share
> same circuit board and most the components on it. The only difference is Hamoa
> SOM board has Hamoa SoC while Purwa SOM board has Purwa SoC.
> 
> I agree they are not same PCB since the SoCs are different. 
> 
> However, I still think it's better to use common dtsi iq-x-iot-som.dtsi since their
> hardware design is very similar. 
> 
> I'll invite Konrad to chime in here as author of x1-crd.dtsi and Qualcomm SoC
> maintainer. I think we are facing similar case on purwa evk and purwa crd.
> Align to same strategy for device tree topology would be good.

Hamoa CRD vs Purwa CRD are literally a just a SoC swapped PCB as far as
I'm aware

Konrad

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Konrad Dybcio]

On 12/24/25 3:02 AM, Yijie Yang wrote:
> 
> 
> On 12/24/2025 1:27 AM, Konrad Dybcio wrote:
>> On 12/23/25 3:12 AM, Yijie Yang wrote:
>>>
>>>
>>> On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
>>>> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>
>>>>> Introduce the device tree, DT bindings, and driver modifications required
>>>>> to bring up the PURWA-IOT-EVK evaluation board.
>>>>>
>>>>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>>>>> the IQ-X SoC series. Consequently, the two common files in this series are
>>>>> prefixed with 'iq-x-iot' to reflect this relationship.
>>>>>
>>>>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>>>>> except for differences in the BOM. As a result, most of the DTS can be
>>>>> shared between them.
>>>>>
>>>>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>>>>> the PURWA-IOT-EVK carrier board.
>>>>>
>>>>> Hardware delta between Hamoa and Purwa:
>>>>> - Display: Purwa’s display uses a different number of clocks, and its
>>>>>     frequency differs from Hamoa.
>>>>> - GPU: Purwa requires a separate firmware compared to Hamoa.
>>>>
>>>> Is it just a separate firmware, or does it use a different _GPU_?
>>>
>>> It uses a different GPU.
>>
>> I think it would be useful to call this paragraph "Hardware delta between
>> Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
>> about differences between Hamoa-the-SoC and Purwa-the-SoC which we
>> expressed in purwa.dtsi
> 
> I want to provide readers with a comprehensive comparison of the two boards, Hamoa-IoT-EVK and Purwa-IoT-EVK, covering all differences in both the SOM and the carrier board.

Of course - my comment points out that the specific wording of "delta
between Hamoa and Purwa" may be easily misinterpreted as not what you're
saying above

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Dmitry Baryshkov]

On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
> On 29/12/2025 08:38, Yijie Yang wrote:
> > 
> > 
> > On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >> On 29/12/2025 02:23, Tingwei Zhang wrote:
> >>>
> >>>
> >>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
> >>>>
> >>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
> >>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
> >>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> >>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
> >>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
> >>>>>>>>
> >>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
> >>>>>>>> the common components into separate files for better maintainability.
> >>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
> >>>>>>> similar to you, but actually common parts.
> >>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
> >>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
> >>>>>> has Hamoa on it.
> >>>>> I do not speak about boards. Read carefully feedback and respond to the
> >>>>> actual feedback, not some other arguments.
> >>>>>
> >>>>> NAK
> >>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
> >>> Krzysztof,
> >>> Please let me know your opinion on this. This could be a common case for
> >>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
> >>
> >> It's not the same PCB.  You did not really respond to my first message,
> >> so I responded to you - I do not speak about boards. Then again you did
> >> not respond to it and brought some irrelevant arguments.
> >>
> >>> would reduce maintenance effort.
> >>
> >> Does not matter, I do not question this. Why are you responding to some
> >> questions which were never asked?
> >>
> >> DTSI represents actual shared physical aspect and you cannot share SoM
> >> physically. It's not the same PCB, because you do not have a socket on
> >> the SoM.
> > 
> > x1e80100-crd and x1p42100-crd are different boards, yet they share the 
> > same x1-crd.dtsi. Why can’t we apply the same approach here?
> 
> 
> You should ask the authors there, not me. I presume that the baseboard
> is the same or very similar. Or pieces of the baseboard are re-used
> which could be visible in the schematics (same MCN numbers etc).

For me this sounds like a new rule, which didn't exist beforehand. We
have enough foo-common.dtsi fragments, covering similar phones, but we
never required the knowledge of those phones having the same PCB.

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/29/2025 7:27 PM, Konrad Dybcio wrote:
> On 12/29/25 11:19 AM, Tingwei Zhang wrote:
>>
>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>>
>>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>>> the common components into separate files for better maintainability.
>>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>>> similar to you, but actually common parts.
>>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>>> has Hamoa on it. 
>>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>>> actual feedback, not some other arguments.
>>>>>>
>>>>>> NAK
>>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>>> Krzysztof,
>>>> Please let me know your opinion on this. This could be a common case for
>>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>> It's not the same PCB.  You did not really respond to my first message,
>>> so I responded to you - I do not speak about boards. Then again you did
>>> not respond to it and brought some irrelevant arguments.
>>>
>>>> would reduce maintenance effort.
>>> Does not matter, I do not question this. Why are you responding to some
>>> questions which were never asked?
>>>
>>> DTSI represents actual shared physical aspect and you cannot share SoM
>>> physically. It's not the same PCB, because you do not have a socket on
>>> the SoM.
>> I didn't make myself clear enough. The SOM PCB I referred here is just the circuit
>> board excluding the components on it.  Let me rephrase.
>>
>> Hamoa and Purwa SOM boards have very similar hardware design. They share
>> same circuit board and most the components on it. The only difference is Hamoa
>> SOM board has Hamoa SoC while Purwa SOM board has Purwa SoC.
>>
>> I agree they are not same PCB since the SoCs are different. 
>>
>> However, I still think it's better to use common dtsi iq-x-iot-som.dtsi since their
>> hardware design is very similar. 
>>
>> I'll invite Konrad to chime in here as author of x1-crd.dtsi and Qualcomm SoC
>> maintainer. I think we are facing similar case on purwa evk and purwa crd.
>> Align to same strategy for device tree topology would be good.
> Hamoa CRD vs Purwa CRD are literally a just a SoC swapped PCB as far as
> I'm aware
It's the same case for Hamoa IOT SOM vs Purwa IOT SOM.
> Konrad

Re: [PATCH 0/4] Initial patch set for PURWA-IOT-EVK

[Yijie Yang]

On 12/29/2025 8:18 PM, Konrad Dybcio wrote:
> On 12/24/25 3:02 AM, Yijie Yang wrote:
>>
>>
>> On 12/24/2025 1:27 AM, Konrad Dybcio wrote:
>>> On 12/23/25 3:12 AM, Yijie Yang wrote:
>>>>
>>>>
>>>> On 12/22/2025 5:18 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Dec 22, 2025 at 02:03:25PM +0800, YijieYang wrote:
>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>
>>>>>> Introduce the device tree, DT bindings, and driver modifications required
>>>>>> to bring up the PURWA-IOT-EVK evaluation board.
>>>>>>
>>>>>> Purwa and Hamoa are IoT variants of x1p42100 and x1e80100, both based on
>>>>>> the IQ-X SoC series. Consequently, the two common files in this series are
>>>>>> prefixed with 'iq-x-iot' to reflect this relationship.
>>>>>>
>>>>>> PURWA-IOT-EVK shares almost the same hardware design with HAMOA-IOT-EVK,
>>>>>> except for differences in the BOM. As a result, most of the DTS can be
>>>>>> shared between them.
>>>>>>
>>>>>> The changes focus on two key hardware components: the PURWA-IOT-SOM and
>>>>>> the PURWA-IOT-EVK carrier board.
>>>>>>
>>>>>> Hardware delta between Hamoa and Purwa:
>>>>>> - Display: Purwa’s display uses a different number of clocks, and its
>>>>>>      frequency differs from Hamoa.
>>>>>> - GPU: Purwa requires a separate firmware compared to Hamoa.
>>>>>
>>>>> Is it just a separate firmware, or does it use a different _GPU_?
>>>>
>>>> It uses a different GPU.
>>>
>>> I think it would be useful to call this paragraph "Hardware delta between
>>> Hamoa-IoT-SoM/EVK and Purwa-IoT-whatever - because now Dmitry is asking
>>> about differences between Hamoa-the-SoC and Purwa-the-SoC which we
>>> expressed in purwa.dtsi
>>
>> I want to provide readers with a comprehensive comparison of the two boards, Hamoa-IoT-EVK and Purwa-IoT-EVK, covering all differences in both the SOM and the carrier board.
> 
> Of course - my comment points out that the specific wording of "delta
> between Hamoa and Purwa" may be easily misinterpreted as not what you're
> saying above

Okay, I’ll update it.

> 
> Konrad

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 29/12/2025 21:08, Dmitry Baryshkov wrote:
> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>
>>>
>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>
>>>>>
>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>
>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>>>
>>>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>>>> the common components into separate files for better maintainability.
>>>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>>>> similar to you, but actually common parts.
>>>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>>>> has Hamoa on it.
>>>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>>>> actual feedback, not some other arguments.
>>>>>>>
>>>>>>> NAK
>>>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>>>> Krzysztof,
>>>>> Please let me know your opinion on this. This could be a common case for
>>>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>>>
>>>> It's not the same PCB.  You did not really respond to my first message,
>>>> so I responded to you - I do not speak about boards. Then again you did
>>>> not respond to it and brought some irrelevant arguments.
>>>>
>>>>> would reduce maintenance effort.
>>>>
>>>> Does not matter, I do not question this. Why are you responding to some
>>>> questions which were never asked?
>>>>
>>>> DTSI represents actual shared physical aspect and you cannot share SoM
>>>> physically. It's not the same PCB, because you do not have a socket on
>>>> the SoM.
>>>
>>> x1e80100-crd and x1p42100-crd are different boards, yet they share the 
>>> same x1-crd.dtsi. Why can’t we apply the same approach here?
>>
>>
>> You should ask the authors there, not me. I presume that the baseboard
>> is the same or very similar. Or pieces of the baseboard are re-used
>> which could be visible in the schematics (same MCN numbers etc).
> 
> For me this sounds like a new rule, which didn't exist beforehand. We
> have enough foo-common.dtsi fragments, covering similar phones, but we
> never required the knowledge of those phones having the same PCB.

I am speaking about it since 2020? 2021? So how new? Other people in
other SoCs were sometimes speaking about it in 2016 or something

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>>
>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>>
>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>>>>
>>>>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>>>>> the common components into separate files for better maintainability.
>>>>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>>>>> similar to you, but actually common parts.
>>>>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>>>>> has Hamoa on it.
>>>>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>>>>> actual feedback, not some other arguments.
>>>>>>>>
>>>>>>>> NAK
>>>>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>>>>> Krzysztof,
>>>>>> Please let me know your opinion on this. This could be a common case for
>>>>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>>>> It's not the same PCB.  You did not really respond to my first message,
>>>>> so I responded to you - I do not speak about boards. Then again you did
>>>>> not respond to it and brought some irrelevant arguments.
>>>>>
>>>>>> would reduce maintenance effort.
>>>>> Does not matter, I do not question this. Why are you responding to some
>>>>> questions which were never asked?
>>>>>
>>>>> DTSI represents actual shared physical aspect and you cannot share SoM
>>>>> physically. It's not the same PCB, because you do not have a socket on
>>>>> the SoM.
>>>> x1e80100-crd and x1p42100-crd are different boards, yet they share the 
>>>> same x1-crd.dtsi. Why can’t we apply the same approach here?
>>>
>>> You should ask the authors there, not me. I presume that the baseboard
>>> is the same or very similar. Or pieces of the baseboard are re-used
>>> which could be visible in the schematics (same MCN numbers etc).
>> For me this sounds like a new rule, which didn't exist beforehand. We
>> have enough foo-common.dtsi fragments, covering similar phones, but we
>> never required the knowledge of those phones having the same PCB.
> I am speaking about it since 2020? 2021? So how new? Other people in
> other SoCs were sometimes speaking about it in 2016 or something
There’s no doubt that using a common DTSI makes sense when the boards
share the same baseboard.
I think the real question is whether the baseboards are defined so
similarly that they can be treated as the same.
For example, would swapping to a different SoC—similar to the
Hamoa/Purwa CRD scenario—still be acceptable?
Would exchanging components such as the display panel, a single camera
lens (not the sensor, as far as I can tell), or removing the 3D iToF
module[1] still qualify as the “same” board?
In other words, can we consider two boards identical if the underlying
circuit board is the same but a few parts are swapped out?

[1]https://lore.kernel.org/all/20221114095654.34561-3-konrad.dybcio@linaro.org/
> Best regards,
> Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Krzysztof Kozlowski]

On 05/01/2026 06:36, Tingwei Zhang wrote:
> 
> 
> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>>>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>>>
>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>>>
>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>>>>>
>>>>>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>>>>>> the common components into separate files for better maintainability.
>>>>>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>>>>>> similar to you, but actually common parts.
>>>>>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>>>>>> has Hamoa on it.
>>>>>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>>>>>> actual feedback, not some other arguments.
>>>>>>>>>
>>>>>>>>> NAK
>>>>>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>>>>>> Krzysztof,
>>>>>>> Please let me know your opinion on this. This could be a common case for
>>>>>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>>>>> It's not the same PCB.  You did not really respond to my first message,
>>>>>> so I responded to you - I do not speak about boards. Then again you did
>>>>>> not respond to it and brought some irrelevant arguments.
>>>>>>
>>>>>>> would reduce maintenance effort.
>>>>>> Does not matter, I do not question this. Why are you responding to some
>>>>>> questions which were never asked?
>>>>>>
>>>>>> DTSI represents actual shared physical aspect and you cannot share SoM
>>>>>> physically. It's not the same PCB, because you do not have a socket on
>>>>>> the SoM.

HERE - socket.

>>>>> x1e80100-crd and x1p42100-crd are different boards, yet they share the 
>>>>> same x1-crd.dtsi. Why can’t we apply the same approach here?
>>>>
>>>> You should ask the authors there, not me. I presume that the baseboard
>>>> is the same or very similar. Or pieces of the baseboard are re-used
>>>> which could be visible in the schematics (same MCN numbers etc).
>>> For me this sounds like a new rule, which didn't exist beforehand. We
>>> have enough foo-common.dtsi fragments, covering similar phones, but we
>>> never required the knowledge of those phones having the same PCB.
>> I am speaking about it since 2020? 2021? So how new? Other people in
>> other SoCs were sometimes speaking about it in 2016 or something
> There’s no doubt that using a common DTSI makes sense when the boards
> share the same baseboard.
> I think the real question is whether the baseboards are defined so
> similarly that they can be treated as the same.
> For example, would swapping to a different SoC—similar to the
> Hamoa/Purwa CRD scenario—still be acceptable?
> Would exchanging components such as the display panel, a single camera
> lens (not the sensor, as far as I can tell), or removing the 3D iToF
> module[1] still qualify as the “same” board?
> In other words, can we consider two boards identical if the underlying
> circuit board is the same but a few parts are swapped out?

I received IDs of the schematics for these boards, but they are called
"IPC BGA module" and what I saw usually is that BGA modules are not
mountable but solderable. This does not matter that much but should have
been said, because it might mean this is not even a SoM. There are many
SoMs which are BGA, not pluggable or pin-based, but I have just doubts
that authors share everything...

Anyway the BGA modules for Hamoa and Purwa have almost the same
schematics, indeed, except differences in PCI, APC supply and lack of
one PMIC.

If this was the same SoM, just with different SoC soldered, it would
have the same PMICs. Different PMICs means different SoM...

Anyway, I shared my opinion and I am not going to spend more time on
this. It should not be my task to go through schematics and prove that
PMICs differ. Authors should.

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
> On 05/01/2026 06:36, Tingwei Zhang wrote:
>>
>> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
>>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>>>>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>>>>>>>>>> From: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> HAMOA-IOT-EVK and PURWA-IOT-EVK share a similar board design. Extract
>>>>>>>>>>>>> the common components into separate files for better maintainability.
>>>>>>>>>>>> SoMs do not share actual hardware. DTSI does not represent what looks
>>>>>>>>>>>> similar to you, but actually common parts.
>>>>>>>>>>> Purwa SOM board and Hamoa SOM board share same design. They share same PCB.
>>>>>>>>>>> The difference is only on chip. Purwa SOM board has Purwa and Hamoa SOM board
>>>>>>>>>>> has Hamoa on it.
>>>>>>>>>> I do not speak about boards. Read carefully feedback and respond to the
>>>>>>>>>> actual feedback, not some other arguments.
>>>>>>>>>>
>>>>>>>>>> NAK
>>>>>>>>> In this change, the SoM hardware except SoC is described by iq-x-iot-som.dtsi since it's common between Hamoa and Purwa. Hamoa and Purwa SoC hardware is described in hamoa.dtsi and purwa.dtsi. Hamoa-iot-som.dtsi includes iq-x-iot-som.dtsi and hamoa.dtsi. This change could reduce the duplicate code and review effort on a totally new purwa-iot-som.dtsi. If we found any bug, it can be fixed in one common file instead of two separate files. Same idea is used in x1-crd.dtsi. X1e80100-crd.dts include x1-crd.dtsi and hamoa.dtsi.
>>>>>>>> Krzysztof,
>>>>>>>> Please let me know your opinion on this. This could be a common case for
>>>>>>>> Hamoa/Purwa boards share same PCB. Share same dtsi file like x1-crd.dtsi
>>>>>>> It's not the same PCB.  You did not really respond to my first message,
>>>>>>> so I responded to you - I do not speak about boards. Then again you did
>>>>>>> not respond to it and brought some irrelevant arguments.
>>>>>>>
>>>>>>>> would reduce maintenance effort.
>>>>>>> Does not matter, I do not question this. Why are you responding to some
>>>>>>> questions which were never asked?
>>>>>>>
>>>>>>> DTSI represents actual shared physical aspect and you cannot share SoM
>>>>>>> physically. It's not the same PCB, because you do not have a socket on
>>>>>>> the SoM.
> HERE - socket.
>
>>>>>> x1e80100-crd and x1p42100-crd are different boards, yet they share the 
>>>>>> same x1-crd.dtsi. Why can’t we apply the same approach here?
>>>>> You should ask the authors there, not me. I presume that the baseboard
>>>>> is the same or very similar. Or pieces of the baseboard are re-used
>>>>> which could be visible in the schematics (same MCN numbers etc).
>>>> For me this sounds like a new rule, which didn't exist beforehand. We
>>>> have enough foo-common.dtsi fragments, covering similar phones, but we
>>>> never required the knowledge of those phones having the same PCB.
>>> I am speaking about it since 2020? 2021? So how new? Other people in
>>> other SoCs were sometimes speaking about it in 2016 or something
>> There’s no doubt that using a common DTSI makes sense when the boards
>> share the same baseboard.
>> I think the real question is whether the baseboards are defined so
>> similarly that they can be treated as the same.
>> For example, would swapping to a different SoC—similar to the
>> Hamoa/Purwa CRD scenario—still be acceptable?
>> Would exchanging components such as the display panel, a single camera
>> lens (not the sensor, as far as I can tell), or removing the 3D iToF
>> module[1] still qualify as the “same” board?
>> In other words, can we consider two boards identical if the underlying
>> circuit board is the same but a few parts are swapped out?
> I received IDs of the schematics for these boards, but they are called
> "IPC BGA module" and what I saw usually is that BGA modules are not
> mountable but solderable. This does not matter that much but should have
> been said, because it might mean this is not even a SoM. There are many
> SoMs which are BGA, not pluggable or pin-based, but I have just doubts
> that authors share everything...
Thanks for taking the time and review the schematics. That's soldered BGA 
modules. It's SoM since that's a module with minimal system including
SoC, PMIC, DDR. This module is available for customer to order so customer
can focus on carrier board. The hardware and software of SoM can be
reused.
> Anyway the BGA modules for Hamoa and Purwa have almost the same
> schematics, indeed, except differences in PCI, APC supply and lack of
> one PMIC.
Yes. These two modules are very similar.
> If this was the same SoM, just with different SoC soldered, it would
> have the same PMICs. Different PMICs means different SoM...
I agree. It's not same SoM, but they are very similar with same circuit board.
> Anyway, I shared my opinion and I am not going to spend more time on
> this. It should not be my task to go through schematics and prove that
> PMICs differ. Authors should.
We will make it more clear in the description about PMIC difference.
Since we have the agreement that Hamoa/Purwa modules are very similar,
we will use common dtsi in next version. Please let me know if you think
that's not correct thing to do.
> Best regards,
> Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Dmitry Baryshkov]

On Tue, Jan 06, 2026 at 09:24:38AM +0800, Tingwei Zhang wrote:
> 
> 
> On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
> > On 05/01/2026 06:36, Tingwei Zhang wrote:
> >>
> >> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
> >>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
> >>>>> On 29/12/2025 08:38, Yijie Yang wrote:
> >>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
> >>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
> >>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
> >>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:

> > If this was the same SoM, just with different SoC soldered, it would
> > have the same PMICs. Different PMICs means different SoM...
> I agree. It's not same SoM, but they are very similar with same circuit board.
> > Anyway, I shared my opinion and I am not going to spend more time on
> > this. It should not be my task to go through schematics and prove that
> > PMICs differ. Authors should.
> We will make it more clear in the description about PMIC difference.
> Since we have the agreement that Hamoa/Purwa modules are very similar,
> we will use common dtsi in next version. Please let me know if you think
> that's not correct thing to do.

I think, you have been clearly told _not_ _to_. You have agreed that
they are not the same module. So, please stop.

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 1/6/2026 9:47 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 06, 2026 at 09:24:38AM +0800, Tingwei Zhang wrote:
>>
>> On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
>>> On 05/01/2026 06:36, Tingwei Zhang wrote:
>>>> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
>>>>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>>>>>>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>> If this was the same SoM, just with different SoC soldered, it would
>>> have the same PMICs. Different PMICs means different SoM...
>> I agree. It's not same SoM, but they are very similar with same circuit board.
>>> Anyway, I shared my opinion and I am not going to spend more time on
>>> this. It should not be my task to go through schematics and prove that
>>> PMICs differ. Authors should.
>> We will make it more clear in the description about PMIC difference.
>> Since we have the agreement that Hamoa/Purwa modules are very similar,
>> we will use common dtsi in next version. Please let me know if you think
>> that's not correct thing to do.
> I think, you have been clearly told _not_ _to_. You have agreed that
> they are not the same module. So, please stop.
>
From hardware side, I think we are on same page. Hamoa and Purwa modules
are not same SoM, but they are very similar. The only difference is different
SoC, PCI, APC supply and one PMIC. The circuit boards are same.
We have exactly same case on Hamoa/Purwa CRD which uses a common
dtsi.
Can we use common dtsi for the hardware boards which are very similar?
Is that very strict that the hardware boards have to be exactly same?

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Dmitry Baryshkov]

On Tue, Jan 06, 2026 at 11:05:30AM +0800, Tingwei Zhang wrote:
> 
> 
> On 1/6/2026 9:47 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 06, 2026 at 09:24:38AM +0800, Tingwei Zhang wrote:
> >>
> >> On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
> >>> On 05/01/2026 06:36, Tingwei Zhang wrote:
> >>>> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>>>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
> >>>>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
> >>>>>>> On 29/12/2025 08:38, Yijie Yang wrote:
> >>>>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
> >>>>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
> >>>>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
> >>>>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
> >>> If this was the same SoM, just with different SoC soldered, it would
> >>> have the same PMICs. Different PMICs means different SoM...
> >> I agree. It's not same SoM, but they are very similar with same circuit board.
> >>> Anyway, I shared my opinion and I am not going to spend more time on
> >>> this. It should not be my task to go through schematics and prove that
> >>> PMICs differ. Authors should.
> >> We will make it more clear in the description about PMIC difference.
> >> Since we have the agreement that Hamoa/Purwa modules are very similar,
> >> we will use common dtsi in next version. Please let me know if you think
> >> that's not correct thing to do.
> > I think, you have been clearly told _not_ _to_. You have agreed that
> > they are not the same module. So, please stop.
> >
> From hardware side, I think we are on same page. Hamoa and Purwa modules
> are not same SoM, but they are very similar. The only difference is different
> SoC, PCI, APC supply and one PMIC. The circuit boards are same.
> We have exactly same case on Hamoa/Purwa CRD which uses a common
> dtsi.
> Can we use common dtsi for the hardware boards which are very similar?
> Is that very strict that the hardware boards have to be exactly same?

I don't have a very strict opinion about the shared DTSIs. However, I
really want to point out: you got an review comment that it is
unacceptable, you never got a comment that it's fine, nevertheless you
want to ignore that review comment, coming from DT bindings maintainer.
In 99% of the cases _ignoring_ the comment is a very wrong idea.

From my PoV, asking to "Please let me know if you think that's not
correct thing to do." after you got all the previous emails is rude.

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Bjorn Andersson]

On Tue, Jan 06, 2026 at 11:05:30AM +0800, Tingwei Zhang wrote:
> 
> 
> On 1/6/2026 9:47 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 06, 2026 at 09:24:38AM +0800, Tingwei Zhang wrote:
> >>
> >> On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
> >>> On 05/01/2026 06:36, Tingwei Zhang wrote:
> >>>> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>>>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
> >>>>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
> >>>>>>> On 29/12/2025 08:38, Yijie Yang wrote:
> >>>>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
> >>>>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
> >>>>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
> >>>>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
> >>>>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
> >>> If this was the same SoM, just with different SoC soldered, it would
> >>> have the same PMICs. Different PMICs means different SoM...
> >> I agree. It's not same SoM, but they are very similar with same circuit board.
> >>> Anyway, I shared my opinion and I am not going to spend more time on
> >>> this. It should not be my task to go through schematics and prove that
> >>> PMICs differ. Authors should.
> >> We will make it more clear in the description about PMIC difference.
> >> Since we have the agreement that Hamoa/Purwa modules are very similar,
> >> we will use common dtsi in next version. Please let me know if you think
> >> that's not correct thing to do.
> > I think, you have been clearly told _not_ _to_. You have agreed that
> > they are not the same module. So, please stop.
> >
> From hardware side, I think we are on same page. Hamoa and Purwa modules
> are not same SoM, but they are very similar.

"They are very similar."

> The only difference is different SoC, PCI, APC supply and one PMIC.

"They are not the same."

> The circuit boards are same.

"They are exactly the same".

> We have exactly same case on Hamoa/Purwa CRD which uses a common
> dtsi.
> Can we use common dtsi for the hardware boards which are very similar?
> Is that very strict that the hardware boards have to be exactly same?
> 

How about doing what we did for Hamoa and Purwa CRD? Just introduce
both, then let the diff between the files and the refactoring of the
files prove your point that there's good leverage.

It might be a detour on the path to reach exactly what you propose here,
but you're going to do it using data, rather than trying to argue that
they are not only similar, but also not the same and exactly the same,
at once. And none of this will impact the .dtb files, so we can shuffle
things around with limited impact.

Once we have some concrete cases of scale, we'll reach some precedence
and this exercise can be avoided for future targets.


PS. We transitioned away from using marketing names to simplify things,
so I am not keen on accepting something called "iq-x-iot" as an "alias"
for hamoa-* and purwa-*. I can only assume that right around the corner
we would have both "q-8-iot" and "iq-8-iot"?

And yes, it's it perfectly reasonable to reach the conclusion that
calling something x1-crd.dtsi was the wrong thing to do, and if so we'll
fix it. But that at least have similar filename prefix to x1e80100 etc.

Regards,
Bjorn

Re: [PATCH 3/4] arm64: dts: qcom: Commonize IQ-X-IOT DTSI

[Tingwei Zhang]

On 1/6/2026 11:26 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 06, 2026 at 11:05:30AM +0800, Tingwei Zhang wrote:
>>
>> On 1/6/2026 9:47 AM, Dmitry Baryshkov wrote:
>>> On Tue, Jan 06, 2026 at 09:24:38AM +0800, Tingwei Zhang wrote:
>>>> On 1/5/2026 11:09 PM, Krzysztof Kozlowski wrote:
>>>>> On 05/01/2026 06:36, Tingwei Zhang wrote:
>>>>>> On 12/30/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 29/12/2025 21:08, Dmitry Baryshkov wrote:
>>>>>>>> On Mon, Dec 29, 2025 at 09:47:05AM +0100, Krzysztof Kozlowski wrote:
>>>>>>>>> On 29/12/2025 08:38, Yijie Yang wrote:
>>>>>>>>>> On 12/29/2025 3:21 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 29/12/2025 02:23, Tingwei Zhang wrote:
>>>>>>>>>>>> On 12/24/2025 8:12 AM, Tingwei Zhang wrote:
>>>>>>>>>>>>> On 12/23/2025 9:41 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>> On 23/12/2025 04:38, Tingwei Zhang wrote:
>>>>>>>>>>>>>>> On 12/22/2025 5:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>>>> On Mon, Dec 22, 2025 at 02:03:28PM +0800, YijieYang wrote:
>>>>> If this was the same SoM, just with different SoC soldered, it would
>>>>> have the same PMICs. Different PMICs means different SoM...
>>>> I agree. It's not same SoM, but they are very similar with same circuit board.
>>>>> Anyway, I shared my opinion and I am not going to spend more time on
>>>>> this. It should not be my task to go through schematics and prove that
>>>>> PMICs differ. Authors should.
>>>> We will make it more clear in the description about PMIC difference.
>>>> Since we have the agreement that Hamoa/Purwa modules are very similar,
>>>> we will use common dtsi in next version. Please let me know if you think
>>>> that's not correct thing to do.
>>> I think, you have been clearly told _not_ _to_. You have agreed that
>>> they are not the same module. So, please stop.
>>>
>> From hardware side, I think we are on same page. Hamoa and Purwa modules
>> are not same SoM, but they are very similar. The only difference is different
>> SoC, PCI, APC supply and one PMIC. The circuit boards are same.
>> We have exactly same case on Hamoa/Purwa CRD which uses a common
>> dtsi.
>> Can we use common dtsi for the hardware boards which are very similar?
>> Is that very strict that the hardware boards have to be exactly same?
> I don't have a very strict opinion about the shared DTSIs. However, I
> really want to point out: you got an review comment that it is
> unacceptable, you never got a comment that it's fine, nevertheless you
> want to ignore that review comment, coming from DT bindings maintainer.
> In 99% of the cases _ignoring_ the comment is a very wrong idea.
>
> From my PoV, asking to "Please let me know if you think that's not
> correct thing to do." after you got all the previous emails is rude.
>
I had understood that boards with very similar designs could utilize common devices
such as the Hamoa/Purwa CRD, and that we had aligned on the similarity between
the Hamoa and Purwa SoM boards. If this assumption is incorrect, please accept
my apologies.