* [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add IMDT
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
@ 2026-06-10 8:57 ` William Bright
2026-06-10 8:57 ` [PATCH v4 2/4] dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM William Bright
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
Add IMDT (IMD Technologies Ltd) to the vendor prefixes list.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..1484442fa0d9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -783,6 +783,8 @@ patternProperties:
description: ILI Technology Corporation (ILITEK)
"^imagis,.*":
description: Imagis Technologies Co., Ltd.
+ "^imdt,.*":
+ description: IMD Technologies Ltd.
"^img,.*":
description: Imagination Technologies Ltd.
"^imi,.*":
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v4 2/4] dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-10 8:57 ` [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add IMDT William Bright
@ 2026-06-10 8:57 ` William Bright
2026-06-10 8:57 ` [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM William Bright
` (2 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
Document the IMDT QCS8550 SBC which consists of an IMDT QCS8550 SoM
soldered onto an IMDT QCS8550 carrier board.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..ccd7b478e5c9 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1105,6 +1105,13 @@ properties:
- sony,pdx234
- const: qcom,sm8550
+ - items:
+ - enum:
+ - imdt,qcs8550-sbc
+ - const: imdt,qcs8550-som
+ - const: qcom,qcs8550
+ - const: qcom,sm8550
+
- items:
- enum:
- qcom,qcs8550-aim300-aiot
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-10 8:57 ` [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add IMDT William Bright
2026-06-10 8:57 ` [PATCH v4 2/4] dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM William Bright
@ 2026-06-10 8:57 ` William Bright
2026-06-26 15:08 ` Konrad Dybcio
2026-06-10 8:57 ` [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-24 13:34 ` [PATCH v4 0/4] " William Bright
4 siblings, 1 reply; 12+ messages in thread
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
The IMDT QCS8550 SoM is a System-on-Module from IMD Technologies Ltd
built around the Qualcomm QCS8550 SoC. It is intended to be soldered
onto a carrier board that supplies VPH_PWR and exposes the off-module
peripherals.
Add qcs8550-imdt-som.dtsi describing the SoM's PMICs (PM8550, PM8550VE,
PM8550VS, PMK8550) and the apps_rsc PMIC outputs. Compared to other
SM8550/QCS8550 boards, this SoM excludes the PM8550B charger PMIC.
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi | 319 +++++++++++++++++++++++++
1 file changed, 319 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi b/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi
new file mode 100644
index 000000000000..816cbd254dea
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 IMD Technologies Ltd
+ */
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "qcs8550.dtsi"
+#include "pm8550.dtsi"
+#define PMK8550VE_SID 5
+#include "pm8550ve.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-l1-l4-l10-supply = <&vreg_s6g_1p86>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob1>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l11-supply = <&vreg_s4g_1p25>;
+ vdd-l12-supply = <&vreg_s6g_1p86>;
+ vdd-l15-supply = <&vreg_s6g_1p86>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ /*
+ * PMIC outputs whose testpoints lack capacitors are
+ * omitted to prevent accidental use:
+ * L1B_1P8, L4B_1P8, L6B_1P8, L7B_1P8, L8B_1P8,
+ * L13B_3P0, L14B_3P2.
+ * Other outputs are unused.
+ */
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3296000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2720000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3104000>;
+ regulator-max-microvolt = <3104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ 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-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ 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>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l3c_0p9: ldo3 {
+ regulator-name = "vreg_l3c_0p9";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l1d_0p88: ldo1 {
+ regulator-name = "vreg_l1d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ /* ldo2 supplies SM8550 VDD_LPI_MX */
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+
+ vreg_s4e_0p95: smps4 {
+ regulator-name = "vreg_s4e_0p95";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <984000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5e_1p08: smps5 {
+ regulator-name = "vreg_s5e_1p08";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1e_0p88: ldo1 {
+ regulator-name = "vreg_l1e_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2e_0p9: ldo2 {
+ regulator-name = "vreg_l2e_0p9";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ 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>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_s4f_0p5: smps4 {
+ regulator-name = "vreg_s4f_0p5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_0p9: ldo1 {
+ regulator-name = "vreg_l1f_0p9";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_0p88: ldo2 {
+ regulator-name = "vreg_l2f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_0p88: ldo3 {
+ regulator-name = "vreg_l3f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "g";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4g_1p25>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+
+ vreg_s1g_1p25: smps1 {
+ regulator-name = "vreg_s1g_1p25";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2g_0p85: smps2 {
+ regulator-name = "vreg_s2g_0p85";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_0p8: smps3 {
+ regulator-name = "vreg_s3g_0p8";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_1p25: smps4 {
+ regulator-name = "vreg_s4g_1p25";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5g_0p85: smps5 {
+ regulator-name = "vreg_s5g_0p85";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6g_1p86: smps6 {
+ regulator-name = "vreg_s6g_1p86";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1g_1p2: ldo1 {
+ regulator-name = "vreg_l1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&pm8550vs_c {
+ status = "okay";
+};
+
+&pm8550vs_d {
+ status = "okay";
+};
+
+&pm8550vs_d_gpios {
+ status = "okay";
+};
+
+&pm8550vs_e {
+ status = "okay";
+};
+
+&pm8550vs_g {
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32764>;
+};
+
+&xo_board {
+ clock-frequency = <76800000>;
+};
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM
2026-06-10 8:57 ` [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM William Bright
@ 2026-06-26 15:08 ` Konrad Dybcio
0 siblings, 0 replies; 12+ messages in thread
From: Konrad Dybcio @ 2026-06-26 15:08 UTC (permalink / raw)
To: William Bright, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
On 6/10/26 10:57 AM, William Bright wrote:
> The IMDT QCS8550 SoM is a System-on-Module from IMD Technologies Ltd
> built around the Qualcomm QCS8550 SoC. It is intended to be soldered
> onto a carrier board that supplies VPH_PWR and exposes the off-module
> peripherals.
>
> Add qcs8550-imdt-som.dtsi describing the SoM's PMICs (PM8550, PM8550VE,
> PM8550VS, PMK8550) and the apps_rsc PMIC outputs. Compared to other
> SM8550/QCS8550 boards, this SoM excludes the PM8550B charger PMIC.
>
> Assisted-by: Claude:claude-opus-4.7
> Signed-off-by: William Bright <william.bright@imd-tec.com>
> ---
[...]
> +&pm8550vs_d_gpios {
> + status = "okay";
> +};
This is already enabled by default
Konrad
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
` (2 preceding siblings ...)
2026-06-10 8:57 ` [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM William Bright
@ 2026-06-10 8:57 ` William Bright
2026-06-10 9:05 ` sashiko-bot
2026-06-26 15:18 ` Konrad Dybcio
2026-06-24 13:34 ` [PATCH v4 0/4] " William Bright
4 siblings, 2 replies; 12+ messages in thread
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
The IMDT QCS8550 SBC is a two-board design from IMD Technologies Ltd
built around the Qualcomm QCS8550 SoC. An IMDT QCS8550 SoM is soldered
onto the IMDT QCS8550 carrier board that supplies VPH_PWR and exposes
the off-module peripherals.
With this DTS, the board can boot to shell with a UFS rootfs with
debugging through uart7. USB and ethernet also are fully functional.
Features enabled are:
- On-board regulators
- uSD
- UART
- UFS
- PCIe0
- PCIe1
- USB (gadget only)
- Ethernet via LAN7430 (PCIe1)
- ADSP, CDSP
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts | 392 ++++++++++++++++++++++++++
2 files changed, 393 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..26b78cd9127e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -190,6 +190,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs8550-imdt-sbc.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
new file mode 100644
index 000000000000..e8afe683c962
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
@@ -0,0 +1,392 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 IMD Technologies Ltd
+ */
+
+/dts-v1/;
+
+#include "qcs8550-imdt-som.dtsi"
+
+/ {
+ model = "IMDT QCS8550 SBC";
+ compatible = "imdt,qcs8550-sbc", "imdt,qcs8550-som",
+ "qcom,qcs8550", "qcom,sm8550";
+ chassis-type = "embedded";
+
+ aliases {
+ serial0 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ /* Enables 5V_PER, 3V3_PER and 1V8_PER rails. These rails
+ * aren't used by anything within the device-tree but are used
+ * for on board logic level conversion and as rails for
+ * pull-ups.
+ */
+ per_pwr: regulator-per-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "per_pwr";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_per_en_default>;
+
+ gpio = <&tlmm 142 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sdhci_2_vqmmc: regulator-sdhci-2-vqmmc {
+ compatible = "regulator-gpio";
+
+ regulator-name = "sdhci_2_vqmmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-type = "voltage";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_vset_default>;
+
+ gpios = <&tlmm 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ gpios-states = <0>;
+ states = <3300000 0>,
+ <1800000 1>;
+
+ startup-delay-us = <10000>;
+ };
+
+ 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;
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ };
+
+ regulators-3 {
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ };
+
+ regulators-4 {
+ vdd-s4-supply = <&vph_pwr>;
+ };
+
+ regulators-5 {
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+ };
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/sm8550/a740_zap.mbn";
+ /* Zap shader doesn't load so is disabled */
+ status = "disabled";
+};
+
+&i2c_master_hub_0 {
+ status = "okay";
+};
+
+&i2c_hub_2 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ ptn3222: redriver@43 {
+ compatible = "nxp,ptn3222";
+ reg = <0x43>;
+ #phy-cells = <0>;
+
+ vdd1v8-supply = <&vreg_l15b_1p8>;
+ vdd3v3-supply = <&vreg_l5b_3p1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&eusb2_repeater_reset_default>;
+
+ reset-gpios = <&pm8550vs_d_gpios 4 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ipa {
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+ firmware-name = "qcom/sm8550/ipa_fws.mbn";
+ status = "okay";
+};
+
+&iris {
+ status = "okay";
+};
+
+&pcie0 {
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+
+ /*
+ * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
+ * reset de-assert here so any module's chip enable is settled
+ * before pcie0 trains its link.
+ */
+ pinctrl-0 = <&pcie0_default_state>, <&m2e_sdio_resetn_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
+
+ /*
+ * pcie_switch_sel_default and gbe_reset_default are board-init
+ * lines that must be stable before pcie1 trains its link: the
+ * PCIe switch needs its mode-select strap settled, and the
+ * downstream LAN743x must be out of reset to enumerate.
+ * Applying them via pcie1's pinctrl-0 fires them during
+ * qcom-pcie probe, before bus enumeration.
+ */
+ pinctrl-0 = <&pcie1_default_state>,
+ <&pcie_switch_sel_default>,
+ <&gbe_reset_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l3c_0p9>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+ vdda-qref-supply = <&vreg_l1e_0p88>;
+
+ status = "okay";
+};
+
+&pm8550_gpios {
+ sd_card_detect_default: sd-card-detect-default-state {
+ pins = "gpio12";
+ function = "normal";
+ input-enable;
+ output-disable;
+ bias-disable;
+ power-source = <1>; /* 1.8 V */
+ };
+};
+
+&pm8550vs_d_gpios {
+ eusb2_repeater_reset_default: eusb2-repeater-reset-default-state {
+ pins = "gpio4";
+ function = "normal";
+
+ input-enable;
+ output-enable;
+ bias-disable;
+
+ drive-push-pull;
+ power-source = <1>; /* 1.8V */
+ qcom,drive-strength = <3>;
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8550/adsp.mbn",
+ "qcom/sm8550/adsp_dtb.mbn";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8550/cdsp.mbn",
+ "qcom/sm8550/cdsp_dtb.mbn";
+ status = "okay";
+};
+
+&sdc2_default {
+ clk-pins {
+ drive-strength = <16>;
+ };
+
+ cmd-pins {
+ /delete-property/ bias-pull-up;
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ data-pins {
+ /delete-property/ bias-pull-up;
+ bias-disable;
+ drive-strength = <16>;
+ };
+};
+
+&sdhc_2 {
+ cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&sdc2_default>, <&sd_card_detect_default>;
+ pinctrl-1 = <&sdc2_default>, <&sd_card_detect_default>;
+ pinctrl-names = "default", "sleep";
+
+ vqmmc-supply = <&sdhci_2_vqmmc>;
+
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+
+ status = "okay";
+};
+
+&tlmm {
+ /* Reserved I/Os for NFC */
+ gpio-reserved-ranges = <32 8>;
+
+ pwr_per_en_default: pwr-per-en-default-state {
+ pwr-per-en-pins {
+ pins = "gpio142";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ sd_vset_default: sd-vset-default-state {
+ sd-vset-pins {
+ pins = "gpio4";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ /*
+ * Drive LAN743x reset high (de-asserted) when pcie1 probes,
+ * so the PHY enumerates on the bus.
+ */
+ gbe_reset_default: gbe-reset-default-state {
+ pins = "gpio138";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ /*
+ * We drive this GPIO physically high on the M2 Key-E connector
+ * to make sure the module is enabled. An M2 Key-E module could
+ * be using this pin as a chip enable.
+ */
+ m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
+ pins = "gpio41";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ /* Force the on-board PCIe switch to select the GbE upstream
+ * port.
+ */
+ pcie_switch_sel_default: pcie-switch-sel-default-state {
+ pins = "gpio16";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1g_1p2>;
+ vccq-max-microamp = <1200000>;
+ vdd-hba-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1d_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ /delete-property/ usb-role-switch;
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_1_hsphy {
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ phys = <&ptn3222>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l3f_0p88>;
+
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-10 8:57 ` [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
@ 2026-06-10 9:05 ` sashiko-bot
2026-06-26 15:18 ` Konrad Dybcio
1 sibling, 0 replies; 12+ messages in thread
From: sashiko-bot @ 2026-06-10 9:05 UTC (permalink / raw)
To: William Bright; +Cc: robh, conor+dt, devicetree
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Encoding downstream device resets and straps into the PCIe host controller's pinctrl to control boot sequencing.
- [Low] Dangling `enable-active-high` property in `regulator-gpio` without `enable-gpios`.
--
commit 69cdd29642da9fee5fcb6d62c3df7354abac11dc
Author: William Bright <william.bright@imd-tec.com>
arm64: dts: qcom: Add IMDT QCS8550 SBC
This commit adds device tree support for the IMDT QCS8550 SBC. It enables
various peripherals including regulators, UART, UFS, PCIe, USB, and Ethernet.
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
[ ... ]
> + sdhci_2_vqmmc: regulator-sdhci-2-vqmmc {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "sdhci_2_vqmmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-type = "voltage";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd_vset_default>;
> +
> + gpios = <&tlmm 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
[Severity: Low]
Is this enable-active-high property needed here?
This regulator uses regulator-gpio and defines the gpios array for voltage
state selection, but it does not specify an enable-gpios property. Since the
property is dangling, will this trigger a dtbs_check validation warning?
> +
> + gpios-states = <0>;
> + states = <3300000 0>,
> + <1800000 1>;
[ ... ]
> +&pcie0 {
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
> + * reset de-assert here so any module's chip enable is settled
> + * before pcie0 trains its link.
> + */
> + pinctrl-0 = <&pcie0_default_state>, <&m2e_sdio_resetn_default>;
[Severity: Medium]
Is it correct to encode downstream device resets into the PCIe host
controller's pinctrl?
Tying board-level reset pins like the SDIO reset to the PCIe host
controller's pinctrl tightly couples peripheral initialization to the host
driver's state machine.
Should these downstream devices be modeled using PCI child nodes with their
own reset properties or standard power sequencing mechanisms instead, to
avoid unintended GPIO toggling during PCIe suspend and resume?
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
[ ... ]
> +&pcie1 {
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie_switch_sel_default and gbe_reset_default are board-init
> + * lines that must be stable before pcie1 trains its link: the
> + * PCIe switch needs its mode-select strap settled, and the
> + * downstream LAN743x must be out of reset to enumerate.
> + * Applying them via pcie1's pinctrl-0 fires them during
> + * qcom-pcie probe, before bus enumeration.
> + */
> + pinctrl-0 = <&pcie1_default_state>,
> + <&pcie_switch_sel_default>,
> + <&gbe_reset_default>;
[Severity: Medium]
Does assigning the PCIe switch strap and downstream GbE PHY reset to the pcie1
pinctrl violate device tree abstractions?
Similar to pcie0, this couples downstream device initialization directly to
the host controller. Modeling this hardware topology through proper PCI child
nodes might be safer than relying on host driver sequencing.
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com?part=4
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-10 8:57 ` [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
2026-06-10 9:05 ` sashiko-bot
@ 2026-06-26 15:18 ` Konrad Dybcio
2026-06-29 10:25 ` William Bright
1 sibling, 1 reply; 12+ messages in thread
From: Konrad Dybcio @ 2026-06-26 15:18 UTC (permalink / raw)
To: William Bright, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
On 6/10/26 10:57 AM, William Bright wrote:
> The IMDT QCS8550 SBC is a two-board design from IMD Technologies Ltd
> built around the Qualcomm QCS8550 SoC. An IMDT QCS8550 SoM is soldered
> onto the IMDT QCS8550 carrier board that supplies VPH_PWR and exposes
> the off-module peripherals.
[...]
> + /* Enables 5V_PER, 3V3_PER and 1V8_PER rails. These rails
> + * aren't used by anything within the device-tree but are used
> + * for on board logic level conversion and as rails for
> + * pull-ups.
> + */
> + per_pwr: regulator-per-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "per_pwr";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_per_en_default>;
style nit:
property-n
property-names
file-wide
[...]
> +&apps_rsc {
> + regulators-0 {
This way of overriding that is super shaky - instead, use a label,
like:
--- som.dtsi
pm8550_rpmh_regulators: regulators-0 {
...
--- sbc.dts
&pm8550_rpmh_regulators {
foo = bar;
};
[...]
> +&gpu_zap_shader {
> + firmware-name = "qcom/sm8550/a740_zap.mbn";
> + /* Zap shader doesn't load so is disabled */
If your SoC is production fused, you must provide your own ZAP firmware
that's signed by you. Conversely, if you have a software stack that
does not include the Gunyah hypervisor, this is likely not necessary
> + status = "disabled";
> +};
> +
> +&i2c_master_hub_0 {
> + status = "okay";
> +};
> +
> +&i2c_hub_2 {
> + clock-frequency = <400000>;
> + status = "okay";
nit: let's keep a \n before status, everywhere
[...]
> +&pcie0 {
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
> + * reset de-assert here so any module's chip enable is settled
> + * before pcie0 trains its link.
> + */
We now have:
Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
which may come in useful here
[...]
> +&pcie1 {
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie_switch_sel_default and gbe_reset_default are board-init
> + * lines that must be stable before pcie1 trains its link: the
> + * PCIe switch needs its mode-select strap settled, and the
> + * downstream LAN743x must be out of reset to enumerate.
> + * Applying them via pcie1's pinctrl-0 fires them during
> + * qcom-pcie probe, before bus enumeration.
> + */
> + pinctrl-0 = <&pcie1_default_state>,
> + <&pcie_switch_sel_default>,
> + <&gbe_reset_default>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
[...]
> + pwr_per_en_default: pwr-per-en-default-state {
> + pwr-per-en-pins {
> + pins = "gpio142";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
For single-group pin state definitions, you can skip the inner
level and define the properties directly under the -state {} node
> +
> + sd_vset_default: sd-vset-default-state {
> + sd-vset-pins {
> + pins = "gpio4";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
> +
> + /*
> + * Drive LAN743x reset high (de-asserted) when pcie1 probes,
> + * so the PHY enumerates on the bus.
> + */
> + gbe_reset_default: gbe-reset-default-state {
> + pins = "gpio138";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-high;
> + };
> +
> + /*
> + * We drive this GPIO physically high on the M2 Key-E connector
> + * to make sure the module is enabled. An M2 Key-E module could
> + * be using this pin as a chip enable.
> + */
> + m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
> + pins = "gpio41";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-high;
> + };
> +
> + /* Force the on-board PCIe switch to select the GbE upstream
> + * port.
> + */
> + pcie_switch_sel_default: pcie-switch-sel-default-state {
> + pins = "gpio16";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-low;
> + };
Normally this would be handled via an actual driver - see e.g.
Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
https://lore.kernel.org/linux-arm-msm/20260605010022.968612-1-elder@riscstar.com/
Konrad
> +};
> +
> +&uart7 {
> + status = "okay";
> +};
> +
> +&ufs_mem_hc {
> + reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
> +
> + vcc-supply = <&vreg_l17b_2p5>;
> + vcc-max-microamp = <1300000>;
> + vccq-supply = <&vreg_l1g_1p2>;
> + vccq-max-microamp = <1200000>;
> + vdd-hba-supply = <&vreg_l3g_1p2>;
> +
> + status = "okay";
> +};
> +
> +&ufs_mem_phy {
> + vdda-phy-supply = <&vreg_l1d_0p88>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
> +
> + status = "okay";
> +};
> +
> +&usb_1 {
> + /delete-property/ usb-role-switch;
> + dr_mode = "peripheral";
Is it really peripheral-only?
Konrad
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-26 15:18 ` Konrad Dybcio
@ 2026-06-29 10:25 ` William Bright
2026-06-29 14:03 ` Konrad Dybcio
0 siblings, 1 reply; 12+ messages in thread
From: William Bright @ 2026-06-29 10:25 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm
On Fri, Jun 26, 2026 at 05:18:20PM +0200, Konrad Dybcio wrote:
> > +&gpu_zap_shader {
> > + firmware-name = "qcom/sm8550/a740_zap.mbn";
> > + /* Zap shader doesn't load so is disabled */
>
> If your SoC is production fused, you must provide your own ZAP firmware
> that's signed by you. Conversely, if you have a software stack that
> does not include the Gunyah hypervisor, this is likely not necessary
I solved the zap shader failing to load a couple of days ago. U-boot
wasn't fixing up DT memory node correctly so I will enable the zap
shader in V5.
> > + status = "disabled";
> > +};
> > +
> > +&i2c_master_hub_0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c_hub_2 {
> > + clock-frequency = <400000>;
> > + status = "okay";
>
> nit: let's keep a \n before status, everywhere
>
> [...]
>
Ack all of your above feedback regarding formatting, new lines and
ordering.
> > +
> > + sd_vset_default: sd-vset-default-state {
> > + sd-vset-pins {
> > + pins = "gpio4";
> > + function = "gpio";
> > + drive-strength = <16>;
> > + bias-disable;
> > + };
> > + };
> > +
> > + /*
> > + * Drive LAN743x reset high (de-asserted) when pcie1 probes,
> > + * so the PHY enumerates on the bus.
> > + */
> > + gbe_reset_default: gbe-reset-default-state {
> > + pins = "gpio138";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-high;
> > + };
> > +
> > + /*
> > + * We drive this GPIO physically high on the M2 Key-E connector
> > + * to make sure the module is enabled. An M2 Key-E module could
> > + * be using this pin as a chip enable.
> > + */
> > + m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
> > + pins = "gpio41";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-high;
> > + };
> > +
> > + /* Force the on-board PCIe switch to select the GbE upstream
> > + * port.
> > + */
> > + pcie_switch_sel_default: pcie-switch-sel-default-state {
> > + pins = "gpio16";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-disable;
> > + output-low;
> > + };
>
> Normally this would be handled via an actual driver - see e.g.
>
> Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> https://lore.kernel.org/linux-arm-msm/20260605010022.968612-1-elder@riscstar.com/
>
> Konrad
>
The PCIe switch we are using is a NXP CBTU02044HEJ, this is a simple
1->2 switch that is not PCIe enumerable. Given that there isn't support
for this IC already in the kernel and that it will take quite a few
weeks/months for me to cobble something together, I am thinking that it
might make sense to drop PCIe support from this patch-series in V5 and
then submit a seperate patch-series with a driver and bindings for this
IC whenever I get something working. Are you OK with this?
> > +&usb_1 {
> > + /delete-property/ usb-role-switch;
> > + dr_mode = "peripheral";
>
> Is it really peripheral-only?
>
> Konrad
On the SBC we have a TUSB321 for role and orientation detection. I will
add this into the DT in V5 so that both roles are supported.
Thanks again for your feedback,
Will
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-29 10:25 ` William Bright
@ 2026-06-29 14:03 ` Konrad Dybcio
2026-06-30 15:04 ` William Bright
0 siblings, 1 reply; 12+ messages in thread
From: Konrad Dybcio @ 2026-06-29 14:03 UTC (permalink / raw)
To: William Bright, Manivannan Sadhasivam
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, devicetree, linux-kernel, linux-arm-msm
On 6/29/26 12:25 PM, William Bright wrote:
> On Fri, Jun 26, 2026 at 05:18:20PM +0200, Konrad Dybcio wrote:
[...]
> The PCIe switch we are using is a NXP CBTU02044HEJ, this is a simple
> 1->2 switch that is not PCIe enumerable. Given that there isn't support
> for this IC already in the kernel and that it will take quite a few
> weeks/months for me to cobble something together, I am thinking that it
> might make sense to drop PCIe support from this patch-series in V5 and
> then submit a seperate patch-series with a driver and bindings for this
> IC whenever I get something working. Are you OK with this?
Sure
I'm a bit curious why do you have a switch there in the first
place - is there anything else connected to the other port?
Would you like for that to be switchable at runtime?
+Mani will probably be interested
Konrad
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-29 14:03 ` Konrad Dybcio
@ 2026-06-30 15:04 ` William Bright
0 siblings, 0 replies; 12+ messages in thread
From: William Bright @ 2026-06-30 15:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, devicetree,
linux-kernel, linux-arm-msm
On Mon, Jun 29, 2026 at 04:03:18PM +0200, Konrad Dybcio wrote:
> On 6/29/26 12:25 PM, William Bright wrote:
> > On Fri, Jun 26, 2026 at 05:18:20PM +0200, Konrad Dybcio wrote:
>
> [...]
>
> > The PCIe switch we are using is a NXP CBTU02044HEJ, this is a simple
> > 1->2 switch that is not PCIe enumerable. Given that there isn't support
> > for this IC already in the kernel and that it will take quite a few
> > weeks/months for me to cobble something together, I am thinking that it
> > might make sense to drop PCIe support from this patch-series in V5 and
> > then submit a seperate patch-series with a driver and bindings for this
> > IC whenever I get something working. Are you OK with this?
>
> Sure
>
> I'm a bit curious why do you have a switch there in the first
> place - is there anything else connected to the other port?
>
Yeah both PCIe ports are used.
Here's a diagram of both pcie0 and pcie1:
pcie0 pcie1
| |
| |
| |
| |
| v
| +-------------------+
| | PCIe Switch |
| | CBTU02044HEJ |
| +-------------------+
| / \
| / \
| / GPIO16 = Low \ GPIO16 = High
v v v
+-------------------+ +-----------+ +-------------+
| M.2 Key E | | LAN7430 | | M.2 Key B |
| Slot | | (Gigabit | | Slot |
| | | Ethernet) | | |
+-------------------+ +-----------+ +-------------+
We used the CBTU02044HEJ PCIe switch on pcie1 so that we could use pcie1
for ethernet or M.2 Key B with static boot-time selection of either.
My limited understanding is that enumerable PCIe switches are expensive
and hard to get although that might be changing. With pcie0 it looks
like I can just add the Key E connector DT node like you suggested and I
will drop pcie1 support for now.
> Would you like for that to be switchable at runtime?
>
> +Mani will probably be interested
>
> Konrad
I didn't intend for this to be possible but its not a negative if this
can be done. My original plan was to use the below .dtso when using Key
B:
// SPDX-License-Identifier: BSD-3-Clause
/*
* Copyright (c) 2026 IMD Technologies Ltd
*
* There are two options for PCIe routing on the IMDT QCS8550 SBC.
* By default, the PCIe switch is configured to route to the GBE PHY, but
* this can be changed to route to the M.2 slot Key B by setting
* pcie_switch_sel_gpio high
*/
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
&pcie_switch_sel_gpio {
/* Change the PCIe switch so that key B routing is selected by
* inverting the GPIO polarity.
*/
gpios = <16 GPIO_ACTIVE_LOW>;
};
Regards
Will
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
2026-06-10 8:57 [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
` (3 preceding siblings ...)
2026-06-10 8:57 ` [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC William Bright
@ 2026-06-24 13:34 ` William Bright
4 siblings, 0 replies; 12+ messages in thread
From: William Bright @ 2026-06-24 13:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
Hi all,
Another gentle ping on this patch series.
Many thanks,
Will
^ permalink raw reply [flat|nested] 12+ messages in thread