[PATCH 0/4] Initial support for Qualcomm Hamoa IOT EVK board

[PATCH 0/4] Initial support for Qualcomm Hamoa IOT EVK board

[Yijie Yang]

Introduce the device tree, DT bindings, and driver modifications required
to bring up the HAMOA-IOT-EVK evaluation board—based on the X1E80100 SoC—to
a UART shell.
This patch set focuses on two key hardware components: the HAMOA-IOT-SOM
and the HAMOA-IOT-EVK carrier board.
The HAMOA-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 HAMOA-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 this
patch set enables their initial bring-up through proper device tree
configuration and driver support.

Qualcomm SoCs often have multiple product variants, each identified by a
different SoC ID. For instance, the x1e80100 SoC has closely related
variants such as x1e78100 and x1e001de. This diversity in SoC identifiers
can lead to confusion and unnecessary maintenance complexity in the device
tree and related subsystems.
To address this, code names offer a more consistent and project-agnostic
way to represent SoC families. They tend to remain stable across
development efforts.
This patch series introduces "hamoa" as the codename for the x1e80100 SoC.
Going forward, all x1e80100-related variants—including x1e81000 and others
in the same family—will be represented under the "hamoa" designation in the
device tree.
This improves readability, streamlines future maintenance, and aligns with
common naming practices across Qualcomm-based platforms. 

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)

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Yijie Yang (4):
      dt-bindings: arm: qcom: Document HAMOA-IOT-EVK board
      firmware: qcom: scm: Allow QSEECOM on HAMOA-IOT-EVK
      arm64: dts: qcom: Add HAMOA-IOT-SOM platform
      arm64: dts: qcom: Add base HAMOA-IOT-EVK board

 Documentation/devicetree/bindings/arm/qcom.yaml |   9 +-
 arch/arm64/boot/dts/qcom/Makefile               |   1 +
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts      | 835 ++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi     | 607 +++++++++++++++++
 drivers/firmware/qcom/qcom_scm.c                |   1 +
 5 files changed, 1451 insertions(+), 2 deletions(-)
---
base-commit: bf66a1ba8e378d23fde984df2034d909215f5150
change-id: 20250604-hamoa_initial-0cd7036d7271

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

[PATCH 1/4] dt-bindings: arm: qcom: Document HAMOA-IOT-EVK board

[Yijie Yang]

Document the device tree binding for a new board named "EVK" based on
the Qualcomm Hamoa-IoT platform.

The "hamoa" name refers to a family of SoCs that share the same silicon
die but are offered in multiple speed bins. The specific SoC used in
this board is the x1e80100, which represents one such bin within the
Hamoa family.

Although "qcom,hamoa-iot-evk" is introduced as the board-specific
compatible, the fallback compatible remains "qcom,x1e80100" to preserve
compatibility with existing in-kernel drivers and software that already
depend on this identifier.

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

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index ae43b35565808ed27cd8354b9a342545c4a98ed6..83b09ec1100ca03044c832212a99e65cc1177985 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -100,8 +100,8 @@ description: |
         sm8550
         sm8650
         sm8750
-        x1e78100
-        x1e80100
+        x1e78100 # hamoa
+        x1e80100 # hamoa
         x1p42100
 
   There are many devices in the list below that run the standard ChromeOS
@@ -1162,6 +1162,11 @@ properties:
               - qcom,x1p42100-crd
           - const: qcom,x1p42100
 
+      - items:
+          - enum:
+              - qcom,hamoa-iot-evk
+          - const: qcom,x1e80100
+
   # Board compatibles go above
 
   qcom,msm-id:

-- 
2.34.1

[PATCH 2/4] firmware: qcom: scm: Allow QSEECOM on HAMOA-IOT-EVK

[Yijie Yang]

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

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 f63b716be5b027550ae3a987e784f0814ea6d678..0473f563700db72333495dabeec59cc482b717f6 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2000,6 +2000,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "microsoft,blackrock" },
 	{ .compatible = "microsoft,romulus13", },
 	{ .compatible = "microsoft,romulus15", },
+	{ .compatible = "qcom,hamoa-iot-evk" },
 	{ .compatible = "qcom,sc8180x-primus" },
 	{ .compatible = "qcom,x1e001de-devkit" },
 	{ .compatible = "qcom,x1e80100-crd" },

-- 
2.34.1

[PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

The HAMOA-IOT-SOM is a compact computing module that integrates a System
on Chip (SoC) — specifically the x1e80100 — along with essential
components optimized for IoT applications. It is designed to be mounted on
carrier boards, enabling the development of complete embedded systems.

This change enables and overlays the following components:
- Regulators on the SOM
- Reserved memory regions
- PCIe6a and its PHY
- PCIe4 and its PHY
- USB0 through USB6 and their PHYs
- ADSP, CDSP
- WLAN, Bluetooth (M.2 interface)

Written with contributions from Yingying Tang (added PCIe4 and its PHY to
enable WLAN).

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
 1 file changed, 607 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..dad24a6a49ad370aee48a9fd8f4a46f64c2b6348
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include "x1e80100.dtsi"
+#include "x1e80100-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>;
+		};
+	};
+};
+
+&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/hamoa-iot/adsp.mbn",
+			"qcom/hamoa-iot/adsp_dtb.mbn";
+
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
+			"qcom/hamoa-iot/cdsp_dtb.mbn";
+
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <34 2>, /* TPM LP & INT */
+			       <44 4>; /* SPI (TPM) */
+
+	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";
+};

-- 
2.34.1

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

[Yijie Yang]

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

This change enables and overlays the following peripherals on the carrier
board:
- UART
- On-board regulators
- USB Type-C mux
- Pinctrl
- Embedded USB (EUSB) repeaters
- NVMe
- pmic-glink

Written with contributions from Shuai Zhang (added Bluetooth).

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile          |   1 +
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
 2 files changed, 836 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= apq8039-t2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= apq8094-sony-xperia-kitakami-karin_windy.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-db820c.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-ifc6640.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= hamoa-iot-evk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-rdp432-c2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-tplink-archer-ax55-v1.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq5332-rdp441.dtb
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
new file mode 100644
index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -0,0 +1,835 @@
+// 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,x1e80100";
+	chassis-type = "embedded";
+
+	aliases {
+		serial0 = &uart21;
+		serial1 = &uart14;
+	};
+
+	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>;
+					};
+				};
+			};
+		};
+
+		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>;
+					};
+				};
+			};
+		};
+	};
+
+	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;
+	};
+
+	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;
+	};
+
+	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;
+	};
+
+	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-boot-on;
+	};
+
+	/*
+	 * TODO: These two regulators are actually part of the removable M.2
+	 * card and not the CRD 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_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;
+	};
+
+	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>;
+
+		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>;
+				};
+			};
+		};
+	};
+};
+
+&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>;
+};
+
+&tlmm {
+	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;
+	};
+
+
+	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;
+	};
+
+	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_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 = <&eusb6_repeater>;
+};
+
+&usb_mp_hsphy1 {
+	phys = <&eusb3_repeater>;
+};

-- 
2.34.1

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

[Krzysztof Kozlowski]

On 16/07/2025 11:08, Yijie Yang wrote:
> Document the device tree binding for a new board named "EVK" based on
> the Qualcomm Hamoa-IoT platform.
> 
> The "hamoa" name refers to a family of SoCs that share the same silicon
> die but are offered in multiple speed bins. The specific SoC used in
> this board is the x1e80100, which represents one such bin within the
> Hamoa family.
> 
> Although "qcom,hamoa-iot-evk" is introduced as the board-specific
> compatible, the fallback compatible remains "qcom,x1e80100" to preserve
> compatibility with existing in-kernel drivers and software that already
> depend on this identifier.
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index ae43b35565808ed27cd8354b9a342545c4a98ed6..83b09ec1100ca03044c832212a99e65cc1177985 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -100,8 +100,8 @@ description: |
>          sm8550
>          sm8650
>          sm8750
> -        x1e78100
> -        x1e80100
> +        x1e78100 # hamoa
> +        x1e80100 # hamoa


Huh? Why, no drop.


>          x1p42100
>  
>    There are many devices in the list below that run the standard ChromeOS
> @@ -1162,6 +1162,11 @@ properties:
>                - qcom,x1p42100-crd
>            - const: qcom,x1p42100
>  
> +      - items:
> +          - enum:
> +              - qcom,hamoa-iot-evk

Don't duplicate entries. Look how this file is organized.


Best regards,
Krzysztof

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

[Konrad Dybcio]

On 7/16/25 11:30 AM, Krzysztof Kozlowski wrote:
> On 16/07/2025 11:08, Yijie Yang wrote:
>> Document the device tree binding for a new board named "EVK" based on
>> the Qualcomm Hamoa-IoT platform.
>>
>> The "hamoa" name refers to a family of SoCs that share the same silicon
>> die but are offered in multiple speed bins. The specific SoC used in
>> this board is the x1e80100, which represents one such bin within the
>> Hamoa family.
>>
>> Although "qcom,hamoa-iot-evk" is introduced as the board-specific
>> compatible, the fallback compatible remains "qcom,x1e80100" to preserve
>> compatibility with existing in-kernel drivers and software that already
>> depend on this identifier.
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>> index ae43b35565808ed27cd8354b9a342545c4a98ed6..83b09ec1100ca03044c832212a99e65cc1177985 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>> @@ -100,8 +100,8 @@ description: |
>>          sm8550
>>          sm8650
>>          sm8750
>> -        x1e78100
>> -        x1e80100
>> +        x1e78100 # hamoa
>> +        x1e80100 # hamoa
> 
> 
> Huh? Why, no drop.

I suggested this, so that people who read this file for the first
time have an idea of which magic numbers correspond to what magic
name for existing platforms (where new DTs will be expected to include
the codename in the file name (just like this submission) to get away
from SKU/speedbin names).

We can drop it if you insist, but I'd rather keep it for newcomers.

Konrad

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

[Krzysztof Kozlowski]

On 16/07/2025 12:26, Konrad Dybcio wrote:
> On 7/16/25 11:30 AM, Krzysztof Kozlowski wrote:
>> On 16/07/2025 11:08, Yijie Yang wrote:
>>> Document the device tree binding for a new board named "EVK" based on
>>> the Qualcomm Hamoa-IoT platform.
>>>
>>> The "hamoa" name refers to a family of SoCs that share the same silicon
>>> die but are offered in multiple speed bins. The specific SoC used in
>>> this board is the x1e80100, which represents one such bin within the
>>> Hamoa family.
>>>
>>> Although "qcom,hamoa-iot-evk" is introduced as the board-specific
>>> compatible, the fallback compatible remains "qcom,x1e80100" to preserve
>>> compatibility with existing in-kernel drivers and software that already
>>> depend on this identifier.
>>>
>>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++--
>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> index ae43b35565808ed27cd8354b9a342545c4a98ed6..83b09ec1100ca03044c832212a99e65cc1177985 100644
>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>> @@ -100,8 +100,8 @@ description: |
>>>          sm8550
>>>          sm8650
>>>          sm8750
>>> -        x1e78100
>>> -        x1e80100
>>> +        x1e78100 # hamoa
>>> +        x1e80100 # hamoa
>>
>>
>> Huh? Why, no drop.
> 
> I suggested this, so that people who read this file for the first
> time have an idea of which magic numbers correspond to what magic
> name for existing platforms (where new DTs will be expected to include
> the codename in the file name (just like this submission) to get away
> from SKU/speedbin names).

No, I already said it on IRC to Casey, not sure if to you, so repeating
here: kernel is not the place to document the mappings between names and
codenames of some random company products.

>  
> We can drop it if you insist, but I'd rather keep it for newcomers.

Whatever boards are called, hamoa-iot-sdk or pink-pony-iot-sdk, does not
need explanation here. Choose whatever name for the boards, but existing
SoCs do not get renamed and do not get any mappings.


Best regards,
Krzysztof

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

[Yijie Yang]

On 2025-07-16 17:30, Krzysztof Kozlowski wrote:
> On 16/07/2025 11:08, Yijie Yang wrote:
>> Document the device tree binding for a new board named "EVK" based on
>> the Qualcomm Hamoa-IoT platform.
>>
>> The "hamoa" name refers to a family of SoCs that share the same silicon
>> die but are offered in multiple speed bins. The specific SoC used in
>> this board is the x1e80100, which represents one such bin within the
>> Hamoa family.
>>
>> Although "qcom,hamoa-iot-evk" is introduced as the board-specific
>> compatible, the fallback compatible remains "qcom,x1e80100" to preserve
>> compatibility with existing in-kernel drivers and software that already
>> depend on this identifier.
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/qcom.yaml | 9 +++++++--
>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>> index ae43b35565808ed27cd8354b9a342545c4a98ed6..83b09ec1100ca03044c832212a99e65cc1177985 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>> @@ -100,8 +100,8 @@ description: |
>>           sm8550
>>           sm8650
>>           sm8750
>> -        x1e78100
>> -        x1e80100
>> +        x1e78100 # hamoa
>> +        x1e80100 # hamoa
> 
> 
> Huh? Why, no drop.

Okay, I’ll leave it as is.

> 
> 
>>           x1p42100
>>   
>>     There are many devices in the list below that run the standard ChromeOS
>> @@ -1162,6 +1162,11 @@ properties:
>>                 - qcom,x1p42100-crd
>>             - const: qcom,x1p42100
>>   
>> +      - items:
>> +          - enum:
>> +              - qcom,hamoa-iot-evk
> 
> Don't duplicate entries. Look how this file is organized.

Sure, I will merge.

> 
> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

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

[kernel test robot]

:::::: 
:::::: Manual check reason: "dtcheck: binding changes may go via different trees"
:::::: 

BCC: lkp@intel.com
CC: llvm@lists.linux.dev
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20250716-hamoa_initial-v1-4-f6f5d0f9a163@oss.qualcomm.com>
References: <20250716-hamoa_initial-v1-4-f6f5d0f9a163@oss.qualcomm.com>
TO: Yijie Yang <yijie.yang@oss.qualcomm.com>
TO: Bjorn Andersson <andersson@kernel.org>
TO: Konrad Dybcio <konradybcio@kernel.org>
TO: Rob Herring <robh@kernel.org>
TO: Krzysztof Kozlowski <krzk@kernel.org>
TO: Conor Dooley <conor+dt@kernel.org>
CC: Yijie Yang <yijie.yang@oss.qualcomm.com>
CC: linux-arm-msm@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org

Hi Yijie,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bf66a1ba8e378d23fde984df2034d909215f5150]

url:    https://github.com/intel-lab-lkp/linux/commits/Yijie-Yang/dt-bindings-arm-qcom-Document-HAMOA-IOT-EVK-board/20250716-171515
base:   bf66a1ba8e378d23fde984df2034d909215f5150
patch link:    https://lore.kernel.org/r/20250716-hamoa_initial-v1-4-f6f5d0f9a163%40oss.qualcomm.com
patch subject: [PATCH 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
:::::: branch date: 26 hours ago
:::::: commit date: 26 hours ago
config: arm64-randconfig-001-20250717 (https://download.01.org/0day-ci/archive/20250717/202507171934.G0XcPRZB-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250717/202507171934.G0XcPRZB-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202507171934.G0XcPRZB-lkp@intel.com/

dtcheck warnings: (new ones prefixed by >>)
   arch/arm64/boot/dts/qcom/x1e80100.dtsi:4879.11-4889.7: Warning (graph_child_address): /soc@0/usb@a2f8800/usb@a200000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
>> arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts:40.10-51.6: Warning (graph_child_address): /pmic-glink/connector@0/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary

vim +40 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts

215ff44203cf57 Yijie Yang 2025-07-16    9  
215ff44203cf57 Yijie Yang 2025-07-16   10  / {
215ff44203cf57 Yijie Yang 2025-07-16   11  	model = "Qualcomm Technologies, Inc. Hamoa IoT EVK";
215ff44203cf57 Yijie Yang 2025-07-16   12  	compatible = "qcom,hamoa-iot-evk", "qcom,x1e80100";
215ff44203cf57 Yijie Yang 2025-07-16   13  	chassis-type = "embedded";
215ff44203cf57 Yijie Yang 2025-07-16   14  
215ff44203cf57 Yijie Yang 2025-07-16   15  	aliases {
215ff44203cf57 Yijie Yang 2025-07-16   16  		serial0 = &uart21;
215ff44203cf57 Yijie Yang 2025-07-16   17  		serial1 = &uart14;
215ff44203cf57 Yijie Yang 2025-07-16   18  	};
215ff44203cf57 Yijie Yang 2025-07-16   19  
215ff44203cf57 Yijie Yang 2025-07-16   20  	chosen {
215ff44203cf57 Yijie Yang 2025-07-16   21  		stdout-path = "serial0:115200n8";
215ff44203cf57 Yijie Yang 2025-07-16   22  	};
215ff44203cf57 Yijie Yang 2025-07-16   23  
215ff44203cf57 Yijie Yang 2025-07-16   24  	pmic-glink {
215ff44203cf57 Yijie Yang 2025-07-16   25  		compatible = "qcom,x1e80100-pmic-glink",
215ff44203cf57 Yijie Yang 2025-07-16   26  			     "qcom,sm8550-pmic-glink",
215ff44203cf57 Yijie Yang 2025-07-16   27  			     "qcom,pmic-glink";
215ff44203cf57 Yijie Yang 2025-07-16   28  		#address-cells = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   29  		#size-cells = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   30  		orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
215ff44203cf57 Yijie Yang 2025-07-16   31  				    <&tlmm 123 GPIO_ACTIVE_HIGH>,
215ff44203cf57 Yijie Yang 2025-07-16   32  				    <&tlmm 125 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16   33  
215ff44203cf57 Yijie Yang 2025-07-16   34  		connector@0 {
215ff44203cf57 Yijie Yang 2025-07-16   35  			compatible = "usb-c-connector";
215ff44203cf57 Yijie Yang 2025-07-16   36  			reg = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   37  			power-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   38  			data-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   39  
215ff44203cf57 Yijie Yang 2025-07-16  @40  			ports {
215ff44203cf57 Yijie Yang 2025-07-16   41  				#address-cells = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   42  				#size-cells = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   43  
215ff44203cf57 Yijie Yang 2025-07-16   44  				port@0 {
215ff44203cf57 Yijie Yang 2025-07-16   45  					reg = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   46  
215ff44203cf57 Yijie Yang 2025-07-16   47  					pmic_glink_ss0_hs_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16   48  						remote-endpoint = <&usb_1_ss0_dwc3_hs>;
215ff44203cf57 Yijie Yang 2025-07-16   49  					};
215ff44203cf57 Yijie Yang 2025-07-16   50  				};
215ff44203cf57 Yijie Yang 2025-07-16   51  			};
215ff44203cf57 Yijie Yang 2025-07-16   52  		};
215ff44203cf57 Yijie Yang 2025-07-16   53  
215ff44203cf57 Yijie Yang 2025-07-16   54  		connector@1 {
215ff44203cf57 Yijie Yang 2025-07-16   55  			compatible = "usb-c-connector";
215ff44203cf57 Yijie Yang 2025-07-16   56  			reg = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   57  			power-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   58  			data-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   59  
215ff44203cf57 Yijie Yang 2025-07-16   60  			ports {
215ff44203cf57 Yijie Yang 2025-07-16   61  				#address-cells = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   62  				#size-cells = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   63  
215ff44203cf57 Yijie Yang 2025-07-16   64  				port@0 {
215ff44203cf57 Yijie Yang 2025-07-16   65  					reg = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   66  
215ff44203cf57 Yijie Yang 2025-07-16   67  					pmic_glink_ss1_hs_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16   68  						remote-endpoint = <&usb_1_ss1_dwc3_hs>;
215ff44203cf57 Yijie Yang 2025-07-16   69  					};
215ff44203cf57 Yijie Yang 2025-07-16   70  				};
215ff44203cf57 Yijie Yang 2025-07-16   71  
215ff44203cf57 Yijie Yang 2025-07-16   72  				port@1 {
215ff44203cf57 Yijie Yang 2025-07-16   73  					reg = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   74  
215ff44203cf57 Yijie Yang 2025-07-16   75  					pmic_glink_ss1_ss_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16   76  						remote-endpoint = <&retimer_ss1_ss_out>;
215ff44203cf57 Yijie Yang 2025-07-16   77  					};
215ff44203cf57 Yijie Yang 2025-07-16   78  				};
215ff44203cf57 Yijie Yang 2025-07-16   79  
215ff44203cf57 Yijie Yang 2025-07-16   80  				port@2 {
215ff44203cf57 Yijie Yang 2025-07-16   81  					reg = <2>;
215ff44203cf57 Yijie Yang 2025-07-16   82  
215ff44203cf57 Yijie Yang 2025-07-16   83  					pmic_glink_ss1_con_sbu_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16   84  						remote-endpoint = <&retimer_ss1_con_sbu_out>;
215ff44203cf57 Yijie Yang 2025-07-16   85  					};
215ff44203cf57 Yijie Yang 2025-07-16   86  				};
215ff44203cf57 Yijie Yang 2025-07-16   87  			};
215ff44203cf57 Yijie Yang 2025-07-16   88  		};
215ff44203cf57 Yijie Yang 2025-07-16   89  
215ff44203cf57 Yijie Yang 2025-07-16   90  		connector@2 {
215ff44203cf57 Yijie Yang 2025-07-16   91  			compatible = "usb-c-connector";
215ff44203cf57 Yijie Yang 2025-07-16   92  			reg = <2>;
215ff44203cf57 Yijie Yang 2025-07-16   93  			power-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   94  			data-role = "dual";
215ff44203cf57 Yijie Yang 2025-07-16   95  
215ff44203cf57 Yijie Yang 2025-07-16   96  			ports {
215ff44203cf57 Yijie Yang 2025-07-16   97  				#address-cells = <1>;
215ff44203cf57 Yijie Yang 2025-07-16   98  				#size-cells = <0>;
215ff44203cf57 Yijie Yang 2025-07-16   99  
215ff44203cf57 Yijie Yang 2025-07-16  100  				port@0 {
215ff44203cf57 Yijie Yang 2025-07-16  101  					reg = <0>;
215ff44203cf57 Yijie Yang 2025-07-16  102  
215ff44203cf57 Yijie Yang 2025-07-16  103  					pmic_glink_ss2_hs_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16  104  						remote-endpoint = <&usb_1_ss2_dwc3_hs>;
215ff44203cf57 Yijie Yang 2025-07-16  105  					};
215ff44203cf57 Yijie Yang 2025-07-16  106  				};
215ff44203cf57 Yijie Yang 2025-07-16  107  
215ff44203cf57 Yijie Yang 2025-07-16  108  				port@1 {
215ff44203cf57 Yijie Yang 2025-07-16  109  					reg = <1>;
215ff44203cf57 Yijie Yang 2025-07-16  110  
215ff44203cf57 Yijie Yang 2025-07-16  111  					pmic_glink_ss2_ss_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16  112  						remote-endpoint = <&retimer_ss2_ss_out>;
215ff44203cf57 Yijie Yang 2025-07-16  113  					};
215ff44203cf57 Yijie Yang 2025-07-16  114  				};
215ff44203cf57 Yijie Yang 2025-07-16  115  
215ff44203cf57 Yijie Yang 2025-07-16  116  				port@2 {
215ff44203cf57 Yijie Yang 2025-07-16  117  					reg = <2>;
215ff44203cf57 Yijie Yang 2025-07-16  118  
215ff44203cf57 Yijie Yang 2025-07-16  119  					pmic_glink_ss2_con_sbu_in: endpoint {
215ff44203cf57 Yijie Yang 2025-07-16  120  						remote-endpoint = <&retimer_ss2_con_sbu_out>;
215ff44203cf57 Yijie Yang 2025-07-16  121  					};
215ff44203cf57 Yijie Yang 2025-07-16  122  				};
215ff44203cf57 Yijie Yang 2025-07-16  123  			};
215ff44203cf57 Yijie Yang 2025-07-16  124  		};
215ff44203cf57 Yijie Yang 2025-07-16  125  	};
215ff44203cf57 Yijie Yang 2025-07-16  126  
215ff44203cf57 Yijie Yang 2025-07-16  127  	vph_pwr: regulator-vph-pwr {
215ff44203cf57 Yijie Yang 2025-07-16  128  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  129  
215ff44203cf57 Yijie Yang 2025-07-16  130  		regulator-name = "vph_pwr";
215ff44203cf57 Yijie Yang 2025-07-16  131  		regulator-min-microvolt = <3700000>;
215ff44203cf57 Yijie Yang 2025-07-16  132  		regulator-max-microvolt = <3700000>;
215ff44203cf57 Yijie Yang 2025-07-16  133  
215ff44203cf57 Yijie Yang 2025-07-16  134  		regulator-always-on;
215ff44203cf57 Yijie Yang 2025-07-16  135  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  136  	};
215ff44203cf57 Yijie Yang 2025-07-16  137  
215ff44203cf57 Yijie Yang 2025-07-16  138  	vreg_nvme: regulator-nvme {
215ff44203cf57 Yijie Yang 2025-07-16  139  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  140  
215ff44203cf57 Yijie Yang 2025-07-16  141  		regulator-name = "VREG_NVME_3P3";
215ff44203cf57 Yijie Yang 2025-07-16  142  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  143  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  144  
215ff44203cf57 Yijie Yang 2025-07-16  145  		gpio = <&tlmm 18 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  146  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  147  
215ff44203cf57 Yijie Yang 2025-07-16  148  		pinctrl-0 = <&nvme_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  149  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  150  
215ff44203cf57 Yijie Yang 2025-07-16  151  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  152  	};
215ff44203cf57 Yijie Yang 2025-07-16  153  
215ff44203cf57 Yijie Yang 2025-07-16  154  	vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
215ff44203cf57 Yijie Yang 2025-07-16  155  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  156  
215ff44203cf57 Yijie Yang 2025-07-16  157  		regulator-name = "VREG_RTMR0_1P15";
215ff44203cf57 Yijie Yang 2025-07-16  158  		regulator-min-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  159  		regulator-max-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  160  
215ff44203cf57 Yijie Yang 2025-07-16  161  		gpio = <&pmc8380_5_gpios 8 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  162  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  163  
215ff44203cf57 Yijie Yang 2025-07-16  164  		pinctrl-0 = <&usb0_pwr_1p15_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  165  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  166  
215ff44203cf57 Yijie Yang 2025-07-16  167  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  168  	};
215ff44203cf57 Yijie Yang 2025-07-16  169  
215ff44203cf57 Yijie Yang 2025-07-16  170  	vreg_rtmr0_1p8: regulator-rtmr0-1p8 {
215ff44203cf57 Yijie Yang 2025-07-16  171  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  172  
215ff44203cf57 Yijie Yang 2025-07-16  173  		regulator-name = "VREG_RTMR0_1P8";
215ff44203cf57 Yijie Yang 2025-07-16  174  		regulator-min-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  175  		regulator-max-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  176  
215ff44203cf57 Yijie Yang 2025-07-16  177  		gpio = <&pm8550ve_9_gpios 8 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  178  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  179  
215ff44203cf57 Yijie Yang 2025-07-16  180  		pinctrl-0 = <&usb0_1p8_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  181  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  182  
215ff44203cf57 Yijie Yang 2025-07-16  183  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  184  	};
215ff44203cf57 Yijie Yang 2025-07-16  185  
215ff44203cf57 Yijie Yang 2025-07-16  186  	vreg_rtmr0_3p3: regulator-rtmr0-3p3 {
215ff44203cf57 Yijie Yang 2025-07-16  187  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  188  
215ff44203cf57 Yijie Yang 2025-07-16  189  		regulator-name = "VREG_RTMR0_3P3";
215ff44203cf57 Yijie Yang 2025-07-16  190  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  191  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  192  
215ff44203cf57 Yijie Yang 2025-07-16  193  		gpio = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  194  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  195  
215ff44203cf57 Yijie Yang 2025-07-16  196  		pinctrl-0 = <&usb0_3p3_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  197  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  198  
215ff44203cf57 Yijie Yang 2025-07-16  199  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  200  	};
215ff44203cf57 Yijie Yang 2025-07-16  201  
215ff44203cf57 Yijie Yang 2025-07-16  202  	vreg_rtmr1_1p15: regulator-rtmr1-1p15 {
215ff44203cf57 Yijie Yang 2025-07-16  203  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  204  
215ff44203cf57 Yijie Yang 2025-07-16  205  		regulator-name = "VREG_RTMR1_1P15";
215ff44203cf57 Yijie Yang 2025-07-16  206  		regulator-min-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  207  		regulator-max-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  208  
215ff44203cf57 Yijie Yang 2025-07-16  209  		gpio = <&tlmm 188 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  210  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  211  
215ff44203cf57 Yijie Yang 2025-07-16  212  		pinctrl-0 = <&usb1_pwr_1p15_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  213  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  214  
215ff44203cf57 Yijie Yang 2025-07-16  215  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  216  	};
215ff44203cf57 Yijie Yang 2025-07-16  217  
215ff44203cf57 Yijie Yang 2025-07-16  218  	vreg_rtmr1_1p8: regulator-rtmr1-1p8 {
215ff44203cf57 Yijie Yang 2025-07-16  219  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  220  
215ff44203cf57 Yijie Yang 2025-07-16  221  		regulator-name = "VREG_RTMR1_1P8";
215ff44203cf57 Yijie Yang 2025-07-16  222  		regulator-min-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  223  		regulator-max-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  224  
215ff44203cf57 Yijie Yang 2025-07-16  225  		gpio = <&tlmm 175 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  226  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  227  
215ff44203cf57 Yijie Yang 2025-07-16  228  		pinctrl-0 = <&usb1_pwr_1p8_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  229  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  230  
215ff44203cf57 Yijie Yang 2025-07-16  231  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  232  	};
215ff44203cf57 Yijie Yang 2025-07-16  233  
215ff44203cf57 Yijie Yang 2025-07-16  234  	vreg_rtmr1_3p3: regulator-rtmr1-3p3 {
215ff44203cf57 Yijie Yang 2025-07-16  235  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  236  
215ff44203cf57 Yijie Yang 2025-07-16  237  		regulator-name = "VREG_RTMR1_3P3";
215ff44203cf57 Yijie Yang 2025-07-16  238  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  239  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  240  
215ff44203cf57 Yijie Yang 2025-07-16  241  		gpio = <&tlmm 186 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  242  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  243  
215ff44203cf57 Yijie Yang 2025-07-16  244  		pinctrl-0 = <&usb1_pwr_3p3_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  245  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  246  
215ff44203cf57 Yijie Yang 2025-07-16  247  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  248  	};
215ff44203cf57 Yijie Yang 2025-07-16  249  
215ff44203cf57 Yijie Yang 2025-07-16  250  	vreg_rtmr2_1p15: regulator-rtmr2-1p15 {
215ff44203cf57 Yijie Yang 2025-07-16  251  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  252  
215ff44203cf57 Yijie Yang 2025-07-16  253  		regulator-name = "VREG_RTMR2_1P15";
215ff44203cf57 Yijie Yang 2025-07-16  254  		regulator-min-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  255  		regulator-max-microvolt = <1150000>;
215ff44203cf57 Yijie Yang 2025-07-16  256  
215ff44203cf57 Yijie Yang 2025-07-16  257  		gpio = <&tlmm 189 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  258  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  259  
215ff44203cf57 Yijie Yang 2025-07-16  260  		pinctrl-0 = <&usb2_pwr_1p15_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  261  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  262  
215ff44203cf57 Yijie Yang 2025-07-16  263  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  264  	};
215ff44203cf57 Yijie Yang 2025-07-16  265  
215ff44203cf57 Yijie Yang 2025-07-16  266  	vreg_rtmr2_1p8: regulator-rtmr2-1p8 {
215ff44203cf57 Yijie Yang 2025-07-16  267  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  268  
215ff44203cf57 Yijie Yang 2025-07-16  269  		regulator-name = "VREG_RTMR2_1P8";
215ff44203cf57 Yijie Yang 2025-07-16  270  		regulator-min-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  271  		regulator-max-microvolt = <1800000>;
215ff44203cf57 Yijie Yang 2025-07-16  272  
215ff44203cf57 Yijie Yang 2025-07-16  273  		gpio = <&tlmm 126 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  274  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  275  
215ff44203cf57 Yijie Yang 2025-07-16  276  		pinctrl-0 = <&usb2_pwr_1p8_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  277  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  278  
215ff44203cf57 Yijie Yang 2025-07-16  279  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  280  	};
215ff44203cf57 Yijie Yang 2025-07-16  281  
215ff44203cf57 Yijie Yang 2025-07-16  282  	vreg_rtmr2_3p3: regulator-rtmr2-3p3 {
215ff44203cf57 Yijie Yang 2025-07-16  283  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  284  
215ff44203cf57 Yijie Yang 2025-07-16  285  		regulator-name = "VREG_RTMR2_3P3";
215ff44203cf57 Yijie Yang 2025-07-16  286  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  287  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  288  
215ff44203cf57 Yijie Yang 2025-07-16  289  		gpio = <&tlmm 187 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  290  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  291  
215ff44203cf57 Yijie Yang 2025-07-16  292  		pinctrl-0 = <&usb2_pwr_3p3_reg_en>;
215ff44203cf57 Yijie Yang 2025-07-16  293  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  294  
215ff44203cf57 Yijie Yang 2025-07-16  295  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  296  	};
215ff44203cf57 Yijie Yang 2025-07-16  297  
215ff44203cf57 Yijie Yang 2025-07-16  298  	vreg_wcn_3p3: regulator-wcn-3p3 {
215ff44203cf57 Yijie Yang 2025-07-16  299  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  300  
215ff44203cf57 Yijie Yang 2025-07-16  301  		regulator-name = "VREG_WCN_3P3";
215ff44203cf57 Yijie Yang 2025-07-16  302  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  303  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  304  
215ff44203cf57 Yijie Yang 2025-07-16  305  		gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  306  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  307  
215ff44203cf57 Yijie Yang 2025-07-16  308  		pinctrl-0 = <&wcn_sw_en>;
215ff44203cf57 Yijie Yang 2025-07-16  309  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  310  
215ff44203cf57 Yijie Yang 2025-07-16  311  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  312  	};
215ff44203cf57 Yijie Yang 2025-07-16  313  
215ff44203cf57 Yijie Yang 2025-07-16  314  	/*
215ff44203cf57 Yijie Yang 2025-07-16  315  	 * TODO: These two regulators are actually part of the removable M.2
215ff44203cf57 Yijie Yang 2025-07-16  316  	 * card and not the CRD mainboard. Need to describe this differently.
215ff44203cf57 Yijie Yang 2025-07-16  317  	 * Functionally it works correctly, because all we need to do is to
215ff44203cf57 Yijie Yang 2025-07-16  318  	 * turn on the actual 3.3V supply above.
215ff44203cf57 Yijie Yang 2025-07-16  319  	 */
215ff44203cf57 Yijie Yang 2025-07-16  320  	vreg_wcn_0p95: regulator-wcn-0p95 {
215ff44203cf57 Yijie Yang 2025-07-16  321  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  322  
215ff44203cf57 Yijie Yang 2025-07-16  323  		regulator-name = "VREG_WCN_0P95";
215ff44203cf57 Yijie Yang 2025-07-16  324  		regulator-min-microvolt = <950000>;
215ff44203cf57 Yijie Yang 2025-07-16  325  		regulator-max-microvolt = <950000>;
215ff44203cf57 Yijie Yang 2025-07-16  326  
215ff44203cf57 Yijie Yang 2025-07-16  327  		vin-supply = <&vreg_wcn_3p3>;
215ff44203cf57 Yijie Yang 2025-07-16  328  	};
215ff44203cf57 Yijie Yang 2025-07-16  329  
215ff44203cf57 Yijie Yang 2025-07-16  330  	vreg_wcn_1p9: regulator-wcn-1p9 {
215ff44203cf57 Yijie Yang 2025-07-16  331  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  332  
215ff44203cf57 Yijie Yang 2025-07-16  333  		regulator-name = "VREG_WCN_1P9";
215ff44203cf57 Yijie Yang 2025-07-16  334  		regulator-min-microvolt = <1900000>;
215ff44203cf57 Yijie Yang 2025-07-16  335  		regulator-max-microvolt = <1900000>;
215ff44203cf57 Yijie Yang 2025-07-16  336  
215ff44203cf57 Yijie Yang 2025-07-16  337  		vin-supply = <&vreg_wcn_3p3>;
215ff44203cf57 Yijie Yang 2025-07-16  338  	};
215ff44203cf57 Yijie Yang 2025-07-16  339  
215ff44203cf57 Yijie Yang 2025-07-16  340  	vreg_wwan: regulator-wwan {
215ff44203cf57 Yijie Yang 2025-07-16  341  		compatible = "regulator-fixed";
215ff44203cf57 Yijie Yang 2025-07-16  342  
215ff44203cf57 Yijie Yang 2025-07-16  343  		regulator-name = "SDX_VPH_PWR";
215ff44203cf57 Yijie Yang 2025-07-16  344  		regulator-min-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  345  		regulator-max-microvolt = <3300000>;
215ff44203cf57 Yijie Yang 2025-07-16  346  
215ff44203cf57 Yijie Yang 2025-07-16  347  		gpio = <&tlmm 221 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  348  		enable-active-high;
215ff44203cf57 Yijie Yang 2025-07-16  349  
215ff44203cf57 Yijie Yang 2025-07-16  350  		pinctrl-0 = <&wwan_sw_en>;
215ff44203cf57 Yijie Yang 2025-07-16  351  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  352  
215ff44203cf57 Yijie Yang 2025-07-16  353  		regulator-boot-on;
215ff44203cf57 Yijie Yang 2025-07-16  354  	};
215ff44203cf57 Yijie Yang 2025-07-16  355  
215ff44203cf57 Yijie Yang 2025-07-16  356  	wcn7850-pmu {
215ff44203cf57 Yijie Yang 2025-07-16  357  		compatible = "qcom,wcn7850-pmu";
215ff44203cf57 Yijie Yang 2025-07-16  358  
215ff44203cf57 Yijie Yang 2025-07-16  359  		vdd-supply = <&vreg_wcn_0p95>;
215ff44203cf57 Yijie Yang 2025-07-16  360  		vddio-supply = <&vreg_l15b_1p8>;
215ff44203cf57 Yijie Yang 2025-07-16  361  		vddaon-supply = <&vreg_wcn_0p95>;
215ff44203cf57 Yijie Yang 2025-07-16  362  		vdddig-supply = <&vreg_wcn_0p95>;
215ff44203cf57 Yijie Yang 2025-07-16  363  		vddrfa1p2-supply = <&vreg_wcn_1p9>;
215ff44203cf57 Yijie Yang 2025-07-16  364  		vddrfa1p8-supply = <&vreg_wcn_1p9>;
215ff44203cf57 Yijie Yang 2025-07-16  365  
215ff44203cf57 Yijie Yang 2025-07-16  366  		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
215ff44203cf57 Yijie Yang 2025-07-16  367  
215ff44203cf57 Yijie Yang 2025-07-16  368  		pinctrl-0 = <&wcn_bt_en>;
215ff44203cf57 Yijie Yang 2025-07-16  369  		pinctrl-names = "default";
215ff44203cf57 Yijie Yang 2025-07-16  370  
215ff44203cf57 Yijie Yang 2025-07-16  371  		regulators {
215ff44203cf57 Yijie Yang 2025-07-16  372  			vreg_pmu_rfa_cmn: ldo0 {
215ff44203cf57 Yijie Yang 2025-07-16  373  				regulator-name = "vreg_pmu_rfa_cmn";
215ff44203cf57 Yijie Yang 2025-07-16  374  			};
215ff44203cf57 Yijie Yang 2025-07-16  375  
215ff44203cf57 Yijie Yang 2025-07-16  376  			vreg_pmu_aon_0p59: ldo1 {
215ff44203cf57 Yijie Yang 2025-07-16  377  				regulator-name = "vreg_pmu_aon_0p59";
215ff44203cf57 Yijie Yang 2025-07-16  378  			};
215ff44203cf57 Yijie Yang 2025-07-16  379  
215ff44203cf57 Yijie Yang 2025-07-16  380  			vreg_pmu_wlcx_0p8: ldo2 {
215ff44203cf57 Yijie Yang 2025-07-16  381  				regulator-name = "vreg_pmu_wlcx_0p8";
215ff44203cf57 Yijie Yang 2025-07-16  382  			};
215ff44203cf57 Yijie Yang 2025-07-16  383  
215ff44203cf57 Yijie Yang 2025-07-16  384  			vreg_pmu_wlmx_0p85: ldo3 {
215ff44203cf57 Yijie Yang 2025-07-16  385  				regulator-name = "vreg_pmu_wlmx_0p85";
215ff44203cf57 Yijie Yang 2025-07-16  386  			};
215ff44203cf57 Yijie Yang 2025-07-16  387  
215ff44203cf57 Yijie Yang 2025-07-16  388  			vreg_pmu_btcmx_0p85: ldo4 {
215ff44203cf57 Yijie Yang 2025-07-16  389  				regulator-name = "vreg_pmu_btcmx_0p85";
215ff44203cf57 Yijie Yang 2025-07-16  390  			};
215ff44203cf57 Yijie Yang 2025-07-16  391  
215ff44203cf57 Yijie Yang 2025-07-16  392  			vreg_pmu_rfa_0p8: ldo5 {
215ff44203cf57 Yijie Yang 2025-07-16  393  				regulator-name = "vreg_pmu_rfa_0p8";
215ff44203cf57 Yijie Yang 2025-07-16  394  			};
215ff44203cf57 Yijie Yang 2025-07-16  395  
215ff44203cf57 Yijie Yang 2025-07-16  396  			vreg_pmu_rfa_1p2: ldo6 {
215ff44203cf57 Yijie Yang 2025-07-16  397  				regulator-name = "vreg_pmu_rfa_1p2";
215ff44203cf57 Yijie Yang 2025-07-16  398  			};
215ff44203cf57 Yijie Yang 2025-07-16  399  
215ff44203cf57 Yijie Yang 2025-07-16  400  			vreg_pmu_rfa_1p8: ldo7 {
215ff44203cf57 Yijie Yang 2025-07-16  401  				regulator-name = "vreg_pmu_rfa_1p8";
215ff44203cf57 Yijie Yang 2025-07-16  402  			};
215ff44203cf57 Yijie Yang 2025-07-16  403  
215ff44203cf57 Yijie Yang 2025-07-16  404  			vreg_pmu_pcie_0p9: ldo8 {
215ff44203cf57 Yijie Yang 2025-07-16  405  				regulator-name = "vreg_pmu_pcie_0p9";
215ff44203cf57 Yijie Yang 2025-07-16  406  			};
215ff44203cf57 Yijie Yang 2025-07-16  407  
215ff44203cf57 Yijie Yang 2025-07-16  408  			vreg_pmu_pcie_1p8: ldo9 {
215ff44203cf57 Yijie Yang 2025-07-16  409  				regulator-name = "vreg_pmu_pcie_1p8";
215ff44203cf57 Yijie Yang 2025-07-16  410  			};
215ff44203cf57 Yijie Yang 2025-07-16  411  		};
215ff44203cf57 Yijie Yang 2025-07-16  412  	};
215ff44203cf57 Yijie Yang 2025-07-16  413  };
215ff44203cf57 Yijie Yang 2025-07-16  414  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 0/4] Initial support for Qualcomm Hamoa IOT EVK board

[Rob Herring (Arm)]

On Wed, 16 Jul 2025 17:08:38 +0800, Yijie Yang wrote:
> Introduce the device tree, DT bindings, and driver modifications required
> to bring up the HAMOA-IOT-EVK evaluation board—based on the X1E80100 SoC—to
> a UART shell.
> This patch set focuses on two key hardware components: the HAMOA-IOT-SOM
> and the HAMOA-IOT-EVK carrier board.
> The HAMOA-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 HAMOA-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 this
> patch set enables their initial bring-up through proper device tree
> configuration and driver support.
> 
> Qualcomm SoCs often have multiple product variants, each identified by a
> different SoC ID. For instance, the x1e80100 SoC has closely related
> variants such as x1e78100 and x1e001de. This diversity in SoC identifiers
> can lead to confusion and unnecessary maintenance complexity in the device
> tree and related subsystems.
> To address this, code names offer a more consistent and project-agnostic
> way to represent SoC families. They tend to remain stable across
> development efforts.
> This patch series introduces "hamoa" as the codename for the x1e80100 SoC.
> Going forward, all x1e80100-related variants—including x1e81000 and others
> in the same family—will be represented under the "hamoa" designation in the
> device tree.
> This improves readability, streamlines future maintenance, and aligns with
> common naming practices across Qualcomm-based platforms.
> 
> 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)
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> Yijie Yang (4):
>       dt-bindings: arm: qcom: Document HAMOA-IOT-EVK board
>       firmware: qcom: scm: Allow QSEECOM on HAMOA-IOT-EVK
>       arm64: dts: qcom: Add HAMOA-IOT-SOM platform
>       arm64: dts: qcom: Add base HAMOA-IOT-EVK board
> 
>  Documentation/devicetree/bindings/arm/qcom.yaml |   9 +-
>  arch/arm64/boot/dts/qcom/Makefile               |   1 +
>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts      | 835 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi     | 607 +++++++++++++++++
>  drivers/firmware/qcom/qcom_scm.c                |   1 +
>  5 files changed, 1451 insertions(+), 2 deletions(-)
> ---
> base-commit: bf66a1ba8e378d23fde984df2034d909215f5150
> change-id: 20250604-hamoa_initial-0cd7036d7271
> 
> Best regards,
> --
> Yijie Yang <yijie.yang@oss.qualcomm.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit bf66a1ba8e378d23fde984df2034d909215f5150

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250716-hamoa_initial-v1-0-f6f5d0f9a163@oss.qualcomm.com:

arch/arm64/boot/dts/qcom/hamoa-iot-evk.dtb: pinctrl@f100000 (qcom,x1e80100-tlmm): Unevaluated properties are not allowed ('wcn_usb_sw_n_state' was unexpected)
	from schema $id: http://devicetree.org/schemas/pinctrl/qcom,x1e80100-tlmm.yaml#

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Stephan Gerhold]

On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
> The HAMOA-IOT-SOM is a compact computing module that integrates a System
> on Chip (SoC) — specifically the x1e80100 — along with essential
> components optimized for IoT applications. It is designed to be mounted on
> carrier boards, enabling the development of complete embedded systems.
> 
> This change enables and overlays the following components:
> - Regulators on the SOM
> - Reserved memory regions
> - PCIe6a and its PHY
> - PCIe4 and its PHY
> - USB0 through USB6 and their PHYs
> - ADSP, CDSP
> - WLAN, Bluetooth (M.2 interface)

There is no WLAN in here, it's part of PATCH 4/4 as far as I can tell.
Move it to changelog of PATCH 4/4?

> 
> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
> enable WLAN).
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
>  1 file changed, 607 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
> new file mode 100644
> index 0000000000000000000000000000000000000000..dad24a6a49ad370aee48a9fd8f4a46f64c2b6348
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
> @@ -0,0 +1,607 @@
> [...]
> +&remoteproc_adsp {
> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
> +			"qcom/hamoa-iot/adsp_dtb.mbn";
> +
> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
> +			"qcom/hamoa-iot/cdsp_dtb.mbn";

You say this SoM can be used to build "complete embedded systems", are
you sure they will all use the same firwmare signatures?

If not, this should be in the device-specific DT (i.e. the carrier board
in your case).

> [...]
> +&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";
> +};
> 

Assuming the USB ports are located on the carrier board and not the
SoM(?):

Are carrier boards required to make use of all these USB
ports/interfaces? In my experience it's not unusual that embedded
carrier boards use only the functionality that they need. Maybe this
should just set the common properties and enabling individual ports for
PCIe and USB should be up to the carrier boards.

Thanks,
Stephan

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

[Stephan Gerhold]

On Wed, Jul 16, 2025 at 05:08:42PM +0800, Yijie Yang wrote:
> The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> the Hamoa IoT SoM and a carrier board. Together, they form a complete
> embedded system capable of booting to UART.
> 
> This change enables and overlays the following peripherals on the carrier
> board:
> - UART
> - On-board regulators
> - USB Type-C mux
> - Pinctrl
> - Embedded USB (EUSB) repeaters
> - NVMe
> - pmic-glink
> 
> Written with contributions from Shuai Zhang (added Bluetooth).
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile          |   1 +
>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
>  2 files changed, 836 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= apq8039-t2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= apq8094-sony-xperia-kitakami-karin_windy.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-db820c.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-ifc6640.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= hamoa-iot-evk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-rdp432-c2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-tplink-archer-ax55-v1.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= ipq5332-rdp441.dtb
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> new file mode 100644
> index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> [...]
> +	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-boot-on;
> +	};
> +
> +	/*
> +	 * TODO: These two regulators are actually part of the removable M.2
> +	 * card and not the CRD 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>;
> +	};

Like the TODO comment already says, regulators located on a M.2 card
shouldn't be described as part of the device DT. We need a proper
solution for modelling the M.2 slots together with the standard power
supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
is also the reason why the CRD does not have Bluetooth enabled upstream
yet, this needs to be solved first.

As far as I know, there is no one actively working on addressing this at
the moment. Perhaps you can assign someone at QC to work on solving this
upstream.

Thanks,
Stephan

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Dmitry Baryshkov]

On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
> The HAMOA-IOT-SOM is a compact computing module that integrates a System
> on Chip (SoC) — specifically the x1e80100 — along with essential
> components optimized for IoT applications. It is designed to be mounted on
> carrier boards, enabling the development of complete embedded systems.
> 
> This change enables and overlays the following components:
> - Regulators on the SOM
> - Reserved memory regions
> - PCIe6a and its PHY
> - PCIe4 and its PHY
> - USB0 through USB6 and their PHYs
> - ADSP, CDSP
> - WLAN, Bluetooth (M.2 interface)
> 
> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
> enable WLAN).
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
>  1 file changed, 607 insertions(+)
> 

> +&remoteproc_adsp {
> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
> +			"qcom/hamoa-iot/adsp_dtb.mbn";

Is there a significant difference qcom/x1e80100/adsp.mbn ? If not, can
we use that firmware?

> +
> +	status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
> +			"qcom/hamoa-iot/cdsp_dtb.mbn";
> +
> +	status = "okay";
> +};
> +

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Konrad Dybcio]

On 7/17/25 6:14 PM, Stephan Gerhold wrote:
> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>> on Chip (SoC) — specifically the x1e80100 — along with essential
>> components optimized for IoT applications. It is designed to be mounted on
>> carrier boards, enabling the development of complete embedded systems.
>>
>> This change enables and overlays the following components:
>> - Regulators on the SOM
>> - Reserved memory regions
>> - PCIe6a and its PHY
>> - PCIe4 and its PHY
>> - USB0 through USB6 and their PHYs
>> - ADSP, CDSP
>> - WLAN, Bluetooth (M.2 interface)

[...]

>> +&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";
>> +};
>>
> 
> Assuming the USB ports are located on the carrier board and not the
> SoM(?):
> 
> Are carrier boards required to make use of all these USB
> ports/interfaces? In my experience it's not unusual that embedded
> carrier boards use only the functionality that they need. Maybe this
> should just set the common properties and enabling individual ports for
> PCIe and USB should be up to the carrier boards.

The PHYs are on the SoC and if the kernel is told they're "disabled",
they may possibly be left dangling from the bootloader

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Stephan Gerhold]

On Thu, Jul 17, 2025 at 10:10:05PM +0200, Konrad Dybcio wrote:
> On 7/17/25 6:14 PM, Stephan Gerhold wrote:
> > On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
> >> The HAMOA-IOT-SOM is a compact computing module that integrates a System
> >> on Chip (SoC) — specifically the x1e80100 — along with essential
> >> components optimized for IoT applications. It is designed to be mounted on
> >> carrier boards, enabling the development of complete embedded systems.
> >>
> >> This change enables and overlays the following components:
> >> - Regulators on the SOM
> >> - Reserved memory regions
> >> - PCIe6a and its PHY
> >> - PCIe4 and its PHY
> >> - USB0 through USB6 and their PHYs
> >> - ADSP, CDSP
> >> - WLAN, Bluetooth (M.2 interface)
> 
> [...]
> 
> >> +&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";
> >> +};
> >>
> > 
> > Assuming the USB ports are located on the carrier board and not the
> > SoM(?):
> > 
> > Are carrier boards required to make use of all these USB
> > ports/interfaces? In my experience it's not unusual that embedded
> > carrier boards use only the functionality that they need. Maybe this
> > should just set the common properties and enabling individual ports for
> > PCIe and USB should be up to the carrier boards.
> 
> The PHYs are on the SoC and if the kernel is told they're "disabled",
> they may possibly be left dangling from the bootloader
> 

How is this different from any of the laptops we have upstream? If we're
worried about firmware keeping unused PHYs on, then we should probably
enable all the PHY nodes by default in the SoC .dtsi?

Thanks,
Stephan

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-18 00:14, Stephan Gerhold wrote:
> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>> on Chip (SoC) — specifically the x1e80100 — along with essential
>> components optimized for IoT applications. It is designed to be mounted on
>> carrier boards, enabling the development of complete embedded systems.
>>
>> This change enables and overlays the following components:
>> - Regulators on the SOM
>> - Reserved memory regions
>> - PCIe6a and its PHY
>> - PCIe4 and its PHY
>> - USB0 through USB6 and their PHYs
>> - ADSP, CDSP
>> - WLAN, Bluetooth (M.2 interface)
> 
> There is no WLAN in here, it's part of PATCH 4/4 as far as I can tell.
> Move it to changelog of PATCH 4/4?

There is no WLAN node defined in either the DTS or DTSI files, as its 
power is managed by UEFI. Once PCIe4 was enabled, WLAN was enabled as 
well. So I think it’s better to leave it here, right?

> 
>>
>> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
>> enable WLAN).
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
>>   1 file changed, 607 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..dad24a6a49ad370aee48a9fd8f4a46f64c2b6348
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
>> @@ -0,0 +1,607 @@
>> [...]
>> +&remoteproc_adsp {
>> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
>> +			"qcom/hamoa-iot/adsp_dtb.mbn";
>> +
>> +	status = "okay";
>> +};
>> +
>> +&remoteproc_cdsp {
>> +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
>> +			"qcom/hamoa-iot/cdsp_dtb.mbn";
> 
> You say this SoM can be used to build "complete embedded systems", are
> you sure they will all use the same firwmare signatures?
> 
> If not, this should be in the device-specific DT (i.e. the carrier board
> in your case).

You’re right. I just double-checked, and each board has its own specific 
firmware. I’ll remove it from the carrier board and update the path 
accordingly.

> 
>> [...]
>> +&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";
>> +};
>>
> 
> Assuming the USB ports are located on the carrier board and not the
> SoM(?):
> 
> Are carrier boards required to make use of all these USB
> ports/interfaces? In my experience it's not unusual that embedded
> carrier boards use only the functionality that they need. Maybe this
> should just set the common properties and enabling individual ports for
> PCIe and USB should be up to the carrier boards.
> 
> Thanks,
> Stephan

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-18 02:52, Dmitry Baryshkov wrote:
> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>> on Chip (SoC) — specifically the x1e80100 — along with essential
>> components optimized for IoT applications. It is designed to be mounted on
>> carrier boards, enabling the development of complete embedded systems.
>>
>> This change enables and overlays the following components:
>> - Regulators on the SOM
>> - Reserved memory regions
>> - PCIe6a and its PHY
>> - PCIe4 and its PHY
>> - USB0 through USB6 and their PHYs
>> - ADSP, CDSP
>> - WLAN, Bluetooth (M.2 interface)
>>
>> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
>> enable WLAN).
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
>>   1 file changed, 607 insertions(+)
>>
> 
>> +&remoteproc_adsp {
>> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
>> +			"qcom/hamoa-iot/adsp_dtb.mbn";
> 
> Is there a significant difference qcom/x1e80100/adsp.mbn ? If not, can
> we use that firmware?

I believe there are differences in firmware between it and the EVK, even 
if they’re minor. Therefore, it's better to maintain a dedicated folder 
for each board and move the code to the carrier board.

> 
>> +
>> +	status = "okay";
>> +};
>> +
>> +&remoteproc_cdsp {
>> +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
>> +			"qcom/hamoa-iot/cdsp_dtb.mbn";
>> +
>> +	status = "okay";
>> +};
>> +
> 

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Krzysztof Kozlowski]

On 17/07/2025 20:52, Dmitry Baryshkov wrote:
>>
> 
>> +&remoteproc_adsp {
>> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
>> +			"qcom/hamoa-iot/adsp_dtb.mbn";
> 
> Is there a significant difference qcom/x1e80100/adsp.mbn ? If not, can
> we use that firmware?

Another problem is that we split FW per SoC and the SoC is x1e80100, not
hamoa-iot. This patchset should not bring so many inconsistencies. It
must adhere TO EXISTING rules. You don't get renames of everything just
because company decided on new naming.

We've been there with sa8775p.

Best regards,
Krzysztof

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

[Yijie Yang]

On 2025-07-18 00:37, Stephan Gerhold wrote:
> On Wed, Jul 16, 2025 at 05:08:42PM +0800, Yijie Yang wrote:
>> The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
>> the Hamoa IoT SoM and a carrier board. Together, they form a complete
>> embedded system capable of booting to UART.
>>
>> This change enables and overlays the following peripherals on the carrier
>> board:
>> - UART
>> - On-board regulators
>> - USB Type-C mux
>> - Pinctrl
>> - Embedded USB (EUSB) repeaters
>> - NVMe
>> - pmic-glink
>>
>> Written with contributions from Shuai Zhang (added Bluetooth).
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile          |   1 +
>>   arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
>>   2 files changed, 836 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= apq8039-t2.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= apq8094-sony-xperia-kitakami-karin_windy.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-db820c.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-ifc6640.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)	+= hamoa-iot-evk.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-rdp432-c2.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-tplink-archer-ax55-v1.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5332-rdp441.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
>> [...]
>> +	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-boot-on;
>> +	};
>> +
>> +	/*
>> +	 * TODO: These two regulators are actually part of the removable M.2
>> +	 * card and not the CRD 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>;
>> +	};
> 
> Like the TODO comment already says, regulators located on a M.2 card
> shouldn't be described as part of the device DT. We need a proper
> solution for modelling the M.2 slots together with the standard power
> supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> is also the reason why the CRD does not have Bluetooth enabled upstream
> yet, this needs to be solved first.
> 
> As far as I know, there is no one actively working on addressing this at
> the moment. Perhaps you can assign someone at QC to work on solving this
> upstream.

This power section is now managed by UEFI, rendering these regulator 
nodes unnecessary. Therefore, I will remove them in the next version.

> 
> Thanks,
> Stephan

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Dmitry Baryshkov]

On Fri, Jul 18, 2025 at 02:33:50PM +0800, Yijie Yang wrote:
> 
> 
> On 2025-07-18 02:52, Dmitry Baryshkov wrote:
> > On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
> > > The HAMOA-IOT-SOM is a compact computing module that integrates a System
> > > on Chip (SoC) — specifically the x1e80100 — along with essential
> > > components optimized for IoT applications. It is designed to be mounted on
> > > carrier boards, enabling the development of complete embedded systems.
> > > 
> > > This change enables and overlays the following components:
> > > - Regulators on the SOM
> > > - Reserved memory regions
> > > - PCIe6a and its PHY
> > > - PCIe4 and its PHY
> > > - USB0 through USB6 and their PHYs
> > > - ADSP, CDSP
> > > - WLAN, Bluetooth (M.2 interface)
> > > 
> > > Written with contributions from Yingying Tang (added PCIe4 and its PHY to
> > > enable WLAN).
> > > 
> > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
> > >   1 file changed, 607 insertions(+)
> > > 
> > 
> > > +&remoteproc_adsp {
> > > +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
> > > +			"qcom/hamoa-iot/adsp_dtb.mbn";
> > 
> > Is there a significant difference qcom/x1e80100/adsp.mbn ? If not, can
> > we use that firmware?
> 
> I believe there are differences in firmware between it and the EVK, even if
> they’re minor. Therefore, it's better to maintain a dedicated folder for
> each board and move the code to the carrier board.

Then it's not a 'hamoa-iot'. It should be 'qcom/hamoa/iot-board-name'.
Please submit the firmware to linux-firmware and also move existing
x1e80100 firmware to the 'hamoa' subdir, maintaining the compatibility
x1e80100 -> hamoa symlink.

> 
> > 
> > > +
> > > +	status = "okay";
> > > +};
> > > +
> > > +&remoteproc_cdsp {
> > > +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
> > > +			"qcom/hamoa-iot/cdsp_dtb.mbn";
> > > +
> > > +	status = "okay";
> > > +};
> > > +
> > 
> 
> -- 
> Best Regards,
> Yijie
> 

-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

On Fri, Jul 18, 2025 at 04:19:13PM +0800, Yijie Yang wrote:
> 
> 
> On 2025-07-18 00:37, Stephan Gerhold wrote:
> > On Wed, Jul 16, 2025 at 05:08:42PM +0800, Yijie Yang wrote:
> > > The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> > > the Hamoa IoT SoM and a carrier board. Together, they form a complete
> > > embedded system capable of booting to UART.
> > > 
> > > This change enables and overlays the following peripherals on the carrier
> > > board:
> > > - UART
> > > - On-board regulators
> > > - USB Type-C mux
> > > - Pinctrl
> > > - Embedded USB (EUSB) repeaters
> > > - NVMe
> > > - pmic-glink
> > > 
> > > Written with contributions from Shuai Zhang (added Bluetooth).
> > > 
> > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/Makefile          |   1 +
> > >   arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
> > >   2 files changed, 836 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= apq8039-t2.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8094-sony-xperia-kitakami-karin_windy.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-db820c.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-ifc6640.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM)	+= hamoa-iot-evk.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-rdp432-c2.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-tplink-archer-ax55-v1.dtb
> > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5332-rdp441.dtb
> > > diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > [...]
> > > +	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-boot-on;
> > > +	};
> > > +
> > > +	/*
> > > +	 * TODO: These two regulators are actually part of the removable M.2
> > > +	 * card and not the CRD 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>;
> > > +	};
> > 
> > Like the TODO comment already says, regulators located on a M.2 card
> > shouldn't be described as part of the device DT. We need a proper
> > solution for modelling the M.2 slots together with the standard power
> > supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> > is also the reason why the CRD does not have Bluetooth enabled upstream
> > yet, this needs to be solved first.
> > 
> > As far as I know, there is no one actively working on addressing this at
> > the moment. Perhaps you can assign someone at QC to work on solving this
> > upstream.
> 
> This power section is now managed by UEFI, rendering these regulator nodes
> unnecessary. Therefore, I will remove them in the next version.

No. The regulators for the M.2 slot should be present here so that Linux
doesn't disable them. Which triggers a question: how are they
controlled? I don't see a GPIO line there.

> 
> > 
> > Thanks,
> > Stephan
> 
> -- 
> Best Regards,
> Yijie
> 

-- 
With best wishes
Dmitry

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

[Stephan Gerhold]

On Fri, Jul 18, 2025 at 12:27:34PM +0300, Dmitry Baryshkov wrote:
> On Fri, Jul 18, 2025 at 04:19:13PM +0800, Yijie Yang wrote:
> > On 2025-07-18 00:37, Stephan Gerhold wrote:
> > > On Wed, Jul 16, 2025 at 05:08:42PM +0800, Yijie Yang wrote:
> > > > The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> > > > the Hamoa IoT SoM and a carrier board. Together, they form a complete
> > > > embedded system capable of booting to UART.
> > > > 
> > > > This change enables and overlays the following peripherals on the carrier
> > > > board:
> > > > - UART
> > > > - On-board regulators
> > > > - USB Type-C mux
> > > > - Pinctrl
> > > > - Embedded USB (EUSB) repeaters
> > > > - NVMe
> > > > - pmic-glink
> > > > 
> > > > Written with contributions from Shuai Zhang (added Bluetooth).
> > > > 
> > > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > > ---
> > > >   arch/arm64/boot/dts/qcom/Makefile          |   1 +
> > > >   arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
> > > >   2 files changed, 836 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= apq8039-t2.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8094-sony-xperia-kitakami-karin_windy.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-db820c.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= apq8096-ifc6640.dtb
> > > > +dtb-$(CONFIG_ARCH_QCOM)	+= hamoa-iot-evk.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-rdp432-c2.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5018-tplink-archer-ax55-v1.dtb
> > > >   dtb-$(CONFIG_ARCH_QCOM)	+= ipq5332-rdp441.dtb
> > > > diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > new file mode 100644
> > > > index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > [...]
> > > > +	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-boot-on;
> > > > +	};
> > > > +
> > > > +	/*
> > > > +	 * TODO: These two regulators are actually part of the removable M.2
> > > > +	 * card and not the CRD 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>;
> > > > +	};
> > > 
> > > Like the TODO comment already says, regulators located on a M.2 card
> > > shouldn't be described as part of the device DT. We need a proper
> > > solution for modelling the M.2 slots together with the standard power
> > > supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> > > is also the reason why the CRD does not have Bluetooth enabled upstream
> > > yet, this needs to be solved first.
> > > 
> > > As far as I know, there is no one actively working on addressing this at
> > > the moment. Perhaps you can assign someone at QC to work on solving this
> > > upstream.
> > 
> > This power section is now managed by UEFI, rendering these regulator nodes
> > unnecessary. Therefore, I will remove them in the next version.
> 
> No. The regulators for the M.2 slot should be present here so that Linux
> doesn't disable them. Which triggers a question: how are they
> controlled? I don't see a GPIO line there.
> 

The 0.95V and 1.9V regulators are located on the inserted M.2 *card* and
get automatically enabled by the 3.3V supply of the M.2 *slot*. If you
remove the card or insert a different one, they won't be present. This
is why they shouldn't be part of the DT. The M.2 slot only has a 3.3V
supply and a 1.8V supply.

The only reason why they are here is that the current bindings for the
WCN7850 require describing the whole PMU and internal regulators of the
M.2 card. Ideally, we should have a generic description for the M.2
slot/connector instead.

Thanks,
Stephan

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

[Dmitry Baryshkov]

On Fri, 18 Jul 2025 at 12:33, Stephan Gerhold
<stephan.gerhold@linaro.org> wrote:
>
> On Fri, Jul 18, 2025 at 12:27:34PM +0300, Dmitry Baryshkov wrote:
> > On Fri, Jul 18, 2025 at 04:19:13PM +0800, Yijie Yang wrote:
> > > On 2025-07-18 00:37, Stephan Gerhold wrote:
> > > > On Wed, Jul 16, 2025 at 05:08:42PM +0800, Yijie Yang wrote:
> > > > > The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> > > > > the Hamoa IoT SoM and a carrier board. Together, they form a complete
> > > > > embedded system capable of booting to UART.
> > > > >
> > > > > This change enables and overlays the following peripherals on the carrier
> > > > > board:
> > > > > - UART
> > > > > - On-board regulators
> > > > > - USB Type-C mux
> > > > > - Pinctrl
> > > > > - Embedded USB (EUSB) repeaters
> > > > > - NVMe
> > > > > - pmic-glink
> > > > >
> > > > > Written with contributions from Shuai Zhang (added Bluetooth).
> > > > >
> > > > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > > > ---
> > > > >   arch/arm64/boot/dts/qcom/Makefile          |   1 +
> > > > >   arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 835 +++++++++++++++++++++++++++++
> > > > >   2 files changed, 836 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM)       += apq8039-t2.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8094-sony-xperia-kitakami-karin_windy.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8096-db820c.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += apq8096-ifc6640.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM)        += hamoa-iot-evk.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5018-rdp432-c2.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5018-tplink-archer-ax55-v1.dtb
> > > > >   dtb-$(CONFIG_ARCH_QCOM)       += ipq5332-rdp441.dtb
> > > > > diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > > > [...]
> > > > > +       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-boot-on;
> > > > > +       };
> > > > > +
> > > > > +       /*
> > > > > +        * TODO: These two regulators are actually part of the removable M.2
> > > > > +        * card and not the CRD 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>;
> > > > > +       };
> > > >
> > > > Like the TODO comment already says, regulators located on a M.2 card
> > > > shouldn't be described as part of the device DT. We need a proper
> > > > solution for modelling the M.2 slots together with the standard power
> > > > supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> > > > is also the reason why the CRD does not have Bluetooth enabled upstream
> > > > yet, this needs to be solved first.
> > > >
> > > > As far as I know, there is no one actively working on addressing this at
> > > > the moment. Perhaps you can assign someone at QC to work on solving this
> > > > upstream.
> > >
> > > This power section is now managed by UEFI, rendering these regulator nodes
> > > unnecessary. Therefore, I will remove them in the next version.
> >
> > No. The regulators for the M.2 slot should be present here so that Linux
> > doesn't disable them. Which triggers a question: how are they
> > controlled? I don't see a GPIO line there.
> >
>
> The 0.95V and 1.9V regulators are located on the inserted M.2 *card* and
> get automatically enabled by the 3.3V supply of the M.2 *slot*. If you
> remove the card or insert a different one, they won't be present. This
> is why they shouldn't be part of the DT. The M.2 slot only has a 3.3V
> supply and a 1.8V supply.
>
> The only reason why they are here is that the current bindings for the
> WCN7850 require describing the whole PMU and internal regulators of the
> M.2 card. Ideally, we should have a generic description for the M.2
> slot/connector instead.

Agree.


-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-18 17:26, Dmitry Baryshkov wrote:
> On Fri, Jul 18, 2025 at 02:33:50PM +0800, Yijie Yang wrote:
>>
>>
>> On 2025-07-18 02:52, Dmitry Baryshkov wrote:
>>> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>>>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>>>> on Chip (SoC) — specifically the x1e80100 — along with essential
>>>> components optimized for IoT applications. It is designed to be mounted on
>>>> carrier boards, enabling the development of complete embedded systems.
>>>>
>>>> This change enables and overlays the following components:
>>>> - Regulators on the SOM
>>>> - Reserved memory regions
>>>> - PCIe6a and its PHY
>>>> - PCIe4 and its PHY
>>>> - USB0 through USB6 and their PHYs
>>>> - ADSP, CDSP
>>>> - WLAN, Bluetooth (M.2 interface)
>>>>
>>>> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
>>>> enable WLAN).
>>>>
>>>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 607 ++++++++++++++++++++++++++++
>>>>    1 file changed, 607 insertions(+)
>>>>
>>>
>>>> +&remoteproc_adsp {
>>>> +	firmware-name = "qcom/hamoa-iot/adsp.mbn",
>>>> +			"qcom/hamoa-iot/adsp_dtb.mbn";
>>>
>>> Is there a significant difference qcom/x1e80100/adsp.mbn ? If not, can
>>> we use that firmware?
>>
>> I believe there are differences in firmware between it and the EVK, even if
>> they’re minor. Therefore, it's better to maintain a dedicated folder for
>> each board and move the code to the carrier board.
> 
> Then it's not a 'hamoa-iot'. It should be 'qcom/hamoa/iot-board-name'.
> Please submit the firmware to linux-firmware and also move existing
> x1e80100 firmware to the 'hamoa' subdir, maintaining the compatibility
> x1e80100 -> hamoa symlink.

After looking into the firmware, it appears this board can use the same 
one as the others. I’ll keep the path consistent and avoid making major 
changes in this patch set.

> 
>>
>>>
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&remoteproc_cdsp {
>>>> +	firmware-name = "qcom/hamoa-iot/cdsp.mbn",
>>>> +			"qcom/hamoa-iot/cdsp_dtb.mbn";
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>
>>
>> -- 
>> Best Regards,
>> Yijie
>>
> 

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Krzysztof Kozlowski]

On 16/07/2025 11:08, Yijie Yang wrote:
> The HAMOA-IOT-SOM is a compact computing module that integrates a System
> on Chip (SoC) — specifically the x1e80100 — along with essential
> components optimized for IoT applications. It is designed to be mounted on
> carrier boards, enabling the development of complete embedded systems.
> 
> This change enables and overlays the following components:
> - Regulators on the SOM
> - Reserved memory regions
> - PCIe6a and its PHY
> - PCIe4 and its PHY
> - USB0 through USB6 and their PHYs
> - ADSP, CDSP
> - WLAN, Bluetooth (M.2 interface)
> 
> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
> enable WLAN).
> 
> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> ---

As pointed out by "arm64: dts: qcom: hamoa-iot-evk: Enable display
support" this is incomplete. Adding new SoM or board is one commit. Not
two. Don't split board DTS, which is already prepared/ready, into
multiple fake commits. This is not a release early approach. This is
opposite!

Best regards,
Krzysztof

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-23 14:28, Krzysztof Kozlowski wrote:
> On 16/07/2025 11:08, Yijie Yang wrote:
>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>> on Chip (SoC) — specifically the x1e80100 — along with essential
>> components optimized for IoT applications. It is designed to be mounted on
>> carrier boards, enabling the development of complete embedded systems.
>>
>> This change enables and overlays the following components:
>> - Regulators on the SOM
>> - Reserved memory regions
>> - PCIe6a and its PHY
>> - PCIe4 and its PHY
>> - USB0 through USB6 and their PHYs
>> - ADSP, CDSP
>> - WLAN, Bluetooth (M.2 interface)
>>
>> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
>> enable WLAN).
>>
>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>> ---
> 
> As pointed out by "arm64: dts: qcom: hamoa-iot-evk: Enable display
> support" this is incomplete. Adding new SoM or board is one commit. Not
> two. Don't split board DTS, which is already prepared/ready, into
> multiple fake commits. This is not a release early approach. This is
> opposite!

The inclusion of display support was not intended in the initial patch, 
and it was not ready at the time this series was submitted. Since the 
display patch set was not submitted by me, its timing could not be 
controlled. If preferred, the display-related changes can be merged into 
this patch in the next revision to maintain consistency.

> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-18 04:14, Stephan Gerhold wrote:
> On Thu, Jul 17, 2025 at 10:10:05PM +0200, Konrad Dybcio wrote:
>> On 7/17/25 6:14 PM, Stephan Gerhold wrote:
>>> On Wed, Jul 16, 2025 at 05:08:41PM +0800, Yijie Yang wrote:
>>>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>>>> on Chip (SoC) — specifically the x1e80100 — along with essential
>>>> components optimized for IoT applications. It is designed to be mounted on
>>>> carrier boards, enabling the development of complete embedded systems.
>>>>
>>>> This change enables and overlays the following components:
>>>> - Regulators on the SOM
>>>> - Reserved memory regions
>>>> - PCIe6a and its PHY
>>>> - PCIe4 and its PHY
>>>> - USB0 through USB6 and their PHYs
>>>> - ADSP, CDSP
>>>> - WLAN, Bluetooth (M.2 interface)
>>
>> [...]
>>
>>>> +&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";
>>>> +};
>>>>
>>>
>>> Assuming the USB ports are located on the carrier board and not the
>>> SoM(?):
>>>
>>> Are carrier boards required to make use of all these USB
>>> ports/interfaces? In my experience it's not unusual that embedded
>>> carrier boards use only the functionality that they need. Maybe this
>>> should just set the common properties and enabling individual ports for
>>> PCIe and USB should be up to the carrier boards.
>>
>> The PHYs are on the SoC and if the kernel is told they're "disabled",
>> they may possibly be left dangling from the bootloader
>>
> 
> How is this different from any of the laptops we have upstream? If we're
> worried about firmware keeping unused PHYs on, then we should probably
> enable all the PHY nodes by default in the SoC .dtsi?

Per my understanding, the SoM may be used with various types of 
firmware, some of which might fully initialize all USB PHYs. In 
contrast, laptop platforms typically rely on fixed firmware that only 
initializes what's necessary for boot.

> 
> Thanks,
> Stephan

-- 
Best Regards,
Yijie

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Dmitry Baryshkov]

On Wed, Jul 23, 2025 at 02:44:14PM +0800, Yijie Yang wrote:
> 
> 
> On 2025-07-23 14:28, Krzysztof Kozlowski wrote:
> > On 16/07/2025 11:08, Yijie Yang wrote:
> > > The HAMOA-IOT-SOM is a compact computing module that integrates a System
> > > on Chip (SoC) — specifically the x1e80100 — along with essential
> > > components optimized for IoT applications. It is designed to be mounted on
> > > carrier boards, enabling the development of complete embedded systems.
> > > 
> > > This change enables and overlays the following components:
> > > - Regulators on the SOM
> > > - Reserved memory regions
> > > - PCIe6a and its PHY
> > > - PCIe4 and its PHY
> > > - USB0 through USB6 and their PHYs
> > > - ADSP, CDSP
> > > - WLAN, Bluetooth (M.2 interface)
> > > 
> > > Written with contributions from Yingying Tang (added PCIe4 and its PHY to
> > > enable WLAN).
> > > 
> > > Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
> > > ---
> > 
> > As pointed out by "arm64: dts: qcom: hamoa-iot-evk: Enable display
> > support" this is incomplete. Adding new SoM or board is one commit. Not
> > two. Don't split board DTS, which is already prepared/ready, into
> > multiple fake commits. This is not a release early approach. This is
> > opposite!
> 
> The inclusion of display support was not intended in the initial patch, and
> it was not ready at the time this series was submitted. Since the display
> patch set was not submitted by me, its timing could not be controlled. If
> preferred, the display-related changes can be merged into this patch in the
> next revision to maintain consistency.

This is neither merged nor accepted. Please squash display (and any
other possible forthcoming changes) into this patchset before reposting

-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform

[Yijie Yang]

On 2025-07-23 19:26, Dmitry Baryshkov wrote:
> On Wed, Jul 23, 2025 at 02:44:14PM +0800, Yijie Yang wrote:
>>
>>
>> On 2025-07-23 14:28, Krzysztof Kozlowski wrote:
>>> On 16/07/2025 11:08, Yijie Yang wrote:
>>>> The HAMOA-IOT-SOM is a compact computing module that integrates a System
>>>> on Chip (SoC) — specifically the x1e80100 — along with essential
>>>> components optimized for IoT applications. It is designed to be mounted on
>>>> carrier boards, enabling the development of complete embedded systems.
>>>>
>>>> This change enables and overlays the following components:
>>>> - Regulators on the SOM
>>>> - Reserved memory regions
>>>> - PCIe6a and its PHY
>>>> - PCIe4 and its PHY
>>>> - USB0 through USB6 and their PHYs
>>>> - ADSP, CDSP
>>>> - WLAN, Bluetooth (M.2 interface)
>>>>
>>>> Written with contributions from Yingying Tang (added PCIe4 and its PHY to
>>>> enable WLAN).
>>>>
>>>> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
>>>> ---
>>>
>>> As pointed out by "arm64: dts: qcom: hamoa-iot-evk: Enable display
>>> support" this is incomplete. Adding new SoM or board is one commit. Not
>>> two. Don't split board DTS, which is already prepared/ready, into
>>> multiple fake commits. This is not a release early approach. This is
>>> opposite!
>>
>> The inclusion of display support was not intended in the initial patch, and
>> it was not ready at the time this series was submitted. Since the display
>> patch set was not submitted by me, its timing could not be controlled. If
>> preferred, the display-related changes can be merged into this patch in the
>> next revision to maintain consistency.
> 
> This is neither merged nor accepted. Please squash display (and any
> other possible forthcoming changes) into this patchset before reposting

Sure, I will.

> 

-- 
Best Regards,
Yijie