Add initial support for x1e001de devkit platform. This includes:
-DSPs
-Ethernet (RTL8125BG) over the pcie 5 instance.
-NVme
-Wifi
-USB-C ports
Link: https://www.qualcomm.com/news/releases/2024/05/qualcomm-accelerates-development-for-copilot--pcs-with-snapdrago
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 813 +++++++++++++++++++
2 files changed, 814 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index ae002c7cf126..1cbc7b91389d 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -268,6 +268,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
+dtb-$(CONFIG_ARCH_QCOM) += x1e001de-devkit.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e78100-lenovo-thinkpad-t14s.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-asus-vivobook-s15.dtb
dtb-$(CONFIG_ARCH_QCOM) += x1e80100-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
new file mode 100644
index 000000000000..07b4e60d9b66
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
@@ -0,0 +1,813 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "x1e80100.dtsi"
+#include "x1e80100-pmics.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. X1E001DE Snapdragon Devkit for Windows";
+ compatible = "qcom,x1e001de-devkit", "qcom,x1e001de", "qcom,x1e80100";
+
+ aliases {
+ serial0 = &uart21;
+ };
+
+ 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>;
+
+ /* Back panel port closer to the RJ45 connector */
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_ss0_hs_in: endpoint {
+ remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss0_ss_in: endpoint {
+ remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+ };
+ };
+ };
+ };
+
+ /* Back panel port closer to the audio jack */
+ 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 = <&usb_1_ss1_qmpphy_out>;
+ };
+ };
+ };
+ };
+
+ /* Front panel port */
+ 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 = <&usb_1_ss2_qmpphy_out>;
+ };
+ };
+ };
+ };
+ };
+
+ reserved-memory {
+ linux,cma {
+ compatible = "shared-dma-pool";
+ size = <0x0 0x8000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ 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-names = "default";
+ pinctrl-0 = <&nvme_reg_en>;
+ };
+
+ 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;
+ };
+};
+
+&apps_rsc {
+ 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>;
+ };
+
+ 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>;
+ };
+
+ 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>;
+ };
+ };
+
+ 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>;
+ };
+ };
+
+ 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>;
+ };
+ };
+
+ 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>;
+ };
+ };
+
+ 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>;
+ };
+ };
+
+ 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>;
+ };
+ };
+
+ 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 = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ 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";
+};
+
+&pcie5 {
+ perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+
+ vddpe-3v3-supply = <&vreg_wwan>;
+
+ pinctrl-0 = <&pcie5_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie5_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>;
+
+ vddpe-3v3-supply = <&vreg_nvme>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie6a_default>;
+
+ status = "okay";
+};
+
+&pcie6a_phy {
+ vdda-phy-supply = <&vreg_l1d_0p8>;
+ vdda-pll-supply = <&vreg_l2j_1p2>;
+
+ status = "okay";
+};
+
+&qupv3_0 {
+ status = "okay";
+};
+
+&qupv3_1 {
+ status = "okay";
+};
+
+&qupv3_2 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/x1e80100/devkit/qcadsp8380.mbn",
+ "qcom/x1e80100/devkit/adsp_dtbs.elf";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/x1e80100/devkit/qccdsp8380.mbn",
+ "qcom/x1e80100/devkit/cdsp_dtbs.elf";
+
+ status = "okay";
+};
+
+&smb2360_0_eusb2_repeater {
+ vdd18-supply = <&vreg_l3d_1p8>;
+ vdd3-supply = <&vreg_l2b_3p0>;
+};
+
+&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 {
+ gpio-reserved-ranges = <34 2>, /* Unused */
+ <44 4>, /* SPI (TPM) */
+ <238 1>; /* UFS Reset */
+
+ nvme_reg_en: nvme-reg-en-state {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ 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;
+ };
+ };
+
+ pcie5_default: pcie5-default-state {
+ clkreq-n-pins {
+ pins = "gpio150";
+ function = "pcie5_clk";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio149";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio151";
+ 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;
+ };
+ };
+
+ wwan_sw_en: wwan-sw-en-state {
+ pins = "gpio221";
+ function = "gpio";
+ drive-strength = <4>;
+ bias-disable;
+ };
+};
+
+&uart21 {
+ compatible = "qcom,geni-debug-uart";
+ status = "okay";
+};
+
+&usb_1_ss0_hsphy {
+ vdd-supply = <&vreg_l3j_0p8>;
+ vdda12-supply = <&vreg_l2j_1p2>;
+
+ phys = <&smb2360_0_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_ss0_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l1j_0p8>;
+
+ status = "okay";
+};
+
+&usb_1_ss0 {
+ status = "okay";
+};
+
+&usb_1_ss0_dwc3 {
+ dr_mode = "host";
+};
+
+&usb_1_ss0_dwc3_hs {
+ remote-endpoint = <&pmic_glink_ss0_hs_in>;
+};
+
+&usb_1_ss0_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss0_ss_in>;
+};
+
+&usb_1_ss1_hsphy {
+ vdd-supply = <&vreg_l3j_0p8>;
+ vdda12-supply = <&vreg_l2j_1p2>;
+
+ phys = <&smb2360_1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_ss1_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l2d_0p9>;
+
+ status = "okay";
+};
+
+&usb_1_ss1 {
+ status = "okay";
+};
+
+&usb_1_ss1_dwc3 {
+ dr_mode = "host";
+};
+
+&usb_1_ss1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_ss1_hs_in>;
+};
+
+&usb_1_ss1_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss1_ss_in>;
+};
+
+&usb_1_ss2_hsphy {
+ vdd-supply = <&vreg_l3j_0p8>;
+ vdda12-supply = <&vreg_l2j_1p2>;
+
+ phys = <&smb2360_2_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_ss2_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l2d_0p9>;
+
+ status = "okay";
+};
+
+&usb_1_ss2 {
+ status = "okay";
+};
+
+&usb_1_ss2_dwc3 {
+ dr_mode = "host";
+};
+
+&usb_1_ss2_dwc3_hs {
+ remote-endpoint = <&pmic_glink_ss2_hs_in>;
+};
+
+&usb_1_ss2_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss2_ss_in>;
+};
--
2.34.1On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> Add initial support for x1e001de devkit platform. This includes:
>
> -DSPs
> -Ethernet (RTL8125BG) over the pcie 5 instance.
> -NVme
> -Wifi
> -USB-C ports
>
> Link: https://www.qualcomm.com/news/releases/2024/05/qualcomm-accelerates-development-for-copilot--pcs-with-snapdrago
> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 813 +++++++++++++++++++
> 2 files changed, 814 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index ae002c7cf126..1cbc7b91389d 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -268,6 +268,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += x1e001de-devkit.dtb
> dtb-$(CONFIG_ARCH_QCOM) += x1e78100-lenovo-thinkpad-t14s.dtb
> dtb-$(CONFIG_ARCH_QCOM) += x1e80100-asus-vivobook-s15.dtb
> dtb-$(CONFIG_ARCH_QCOM) += x1e80100-crd.dtb
> diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> new file mode 100644
> index 000000000000..07b4e60d9b66
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> @@ -0,0 +1,813 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +
> +#include "x1e80100.dtsi"
> +#include "x1e80100-pmics.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. X1E001DE Snapdragon Devkit for Windows";
> + compatible = "qcom,x1e001de-devkit", "qcom,x1e001de", "qcom,x1e80100";
> +
> + aliases {
> + serial0 = &uart21;
> + };
> +
> + 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>;
> +
> + /* Back panel port closer to the RJ45 connector */
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> + power-role = "dual";
> + data-role = "dual";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_ss0_hs_in: endpoint {
> + remote-endpoint = <&usb_1_ss0_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pmic_glink_ss0_ss_in: endpoint {
> + remote-endpoint = <&usb_1_ss0_qmpphy_out>;
> + };
> + };
> + };
> + };
> +
> + /* Back panel port closer to the audio jack */
> + 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 = <&usb_1_ss1_qmpphy_out>;
> + };
> + };
> + };
> + };
> +
> + /* Front panel port */
> + connector@2 {
> + compatible = "usb-c-connector";
> + reg = <2>;
> + power-role = "dual";
> + data-role = "dual";
> +
[trimmed]
> +
> +&pcie5 {
> + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> +
> + vddpe-3v3-supply = <&vreg_wwan>;
Please use pwrseq instead.
> +
> + pinctrl-0 = <&pcie5_default>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
> +&pcie5_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>;
> +
> + vddpe-3v3-supply = <&vreg_nvme>;
Please use pwrseq instead.
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie6a_default>;
> +
> + status = "okay";
> +};
> +
> +&pcie6a_phy {
> + vdda-phy-supply = <&vreg_l1d_0p8>;
> + vdda-pll-supply = <&vreg_l2j_1p2>;
> +
> + status = "okay";
> +};
> +
> +&qupv3_0 {
> + status = "okay";
> +};
> +
> +&qupv3_1 {
> + status = "okay";
> +};
> +
> +&qupv3_2 {
> + status = "okay";
> +};
> +
> +&remoteproc_adsp {
> + firmware-name = "qcom/x1e80100/devkit/qcadsp8380.mbn",
> + "qcom/x1e80100/devkit/adsp_dtbs.elf";
qcom/SoC/Vendor/Device/foo.ext. Here the Vendor part is missing.
> +
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/x1e80100/devkit/qccdsp8380.mbn",
> + "qcom/x1e80100/devkit/cdsp_dtbs.elf";
> +
> + status = "okay";
> +};
> +
> +&smb2360_0_eusb2_repeater {
> + vdd18-supply = <&vreg_l3d_1p8>;
> + vdd3-supply = <&vreg_l2b_3p0>;
> +};
> +
> +&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 {
> + gpio-reserved-ranges = <34 2>, /* Unused */
> + <44 4>, /* SPI (TPM) */
> + <238 1>; /* UFS Reset */
A comment would be nice. Usually the GPIOs are reserved because
accessing them is forbidden by TZ / hyp. Is this the case for the Unused
GPIOs? And why is the UFS reset marked as reserved?
> +
> + nvme_reg_en: nvme-reg-en-state {
> + pins = "gpio18";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + 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;
> + };
> + };
> +
> + pcie5_default: pcie5-default-state {
> + clkreq-n-pins {
> + pins = "gpio150";
> + function = "pcie5_clk";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + perst-n-pins {
> + pins = "gpio149";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + wake-n-pins {
> + pins = "gpio151";
> + 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;
> + };
> + };
> +
> + wwan_sw_en: wwan-sw-en-state {
> + pins = "gpio221";
> + function = "gpio";
> + drive-strength = <4>;
> + bias-disable;
> + };
> +};
> +
> +&uart21 {
> + compatible = "qcom,geni-debug-uart";
> + status = "okay";
> +};
> +
> +&usb_1_ss0_hsphy {
> + vdd-supply = <&vreg_l3j_0p8>;
> + vdda12-supply = <&vreg_l2j_1p2>;
> +
> + phys = <&smb2360_0_eusb2_repeater>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss0_qmpphy {
> + vdda-phy-supply = <&vreg_l3e_1p2>;
> + vdda-pll-supply = <&vreg_l1j_0p8>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss0 {
> + status = "okay";
> +};
> +
> +&usb_1_ss0_dwc3 {
> + dr_mode = "host";
> +};
> +
> +&usb_1_ss0_dwc3_hs {
> + remote-endpoint = <&pmic_glink_ss0_hs_in>;
> +};
> +
> +&usb_1_ss0_qmpphy_out {
> + remote-endpoint = <&pmic_glink_ss0_ss_in>;
> +};
> +
> +&usb_1_ss1_hsphy {
> + vdd-supply = <&vreg_l3j_0p8>;
> + vdda12-supply = <&vreg_l2j_1p2>;
> +
> + phys = <&smb2360_1_eusb2_repeater>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss1_qmpphy {
> + vdda-phy-supply = <&vreg_l3e_1p2>;
> + vdda-pll-supply = <&vreg_l2d_0p9>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss1 {
> + status = "okay";
> +};
> +
> +&usb_1_ss1_dwc3 {
> + dr_mode = "host";
All three USB-C connectors have data-role set to "dual". So this needs a
comment.
> +};
> +
> +&usb_1_ss1_dwc3_hs {
> + remote-endpoint = <&pmic_glink_ss1_hs_in>;
> +};
> +
> +&usb_1_ss1_qmpphy_out {
> + remote-endpoint = <&pmic_glink_ss1_ss_in>;
> +};
> +
> +&usb_1_ss2_hsphy {
> + vdd-supply = <&vreg_l3j_0p8>;
> + vdda12-supply = <&vreg_l2j_1p2>;
> +
> + phys = <&smb2360_2_eusb2_repeater>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss2_qmpphy {
> + vdda-phy-supply = <&vreg_l3e_1p2>;
> + vdda-pll-supply = <&vreg_l2d_0p9>;
> +
> + status = "okay";
> +};
> +
> +&usb_1_ss2 {
> + status = "okay";
> +};
> +
> +&usb_1_ss2_dwc3 {
> + dr_mode = "host";
> +};
> +
> +&usb_1_ss2_dwc3_hs {
> + remote-endpoint = <&pmic_glink_ss2_hs_in>;
> +};
> +
> +&usb_1_ss2_qmpphy_out {
> + remote-endpoint = <&pmic_glink_ss2_ss_in>;
> +};
> --
> 2.34.1
>
--
With best wishes
Dmitry
On 9/11/24 13:25, Dmitry Baryshkov wrote:
> On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
>> Add initial support for x1e001de devkit platform. This includes:
>>
>> -DSPs
>> -Ethernet (RTL8125BG) over the pcie 5 instance.
>> -NVme
>> -Wifi
>> -USB-C ports
>>
Hey Dmitry,
Thanks for taking time to review the series!
>> Link: https://www.qualcomm.com/news/releases/2024/05/qualcomm-accelerates-development-for-copilot--pcs-with-snapdrago
>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
>> ---
>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>> arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 813 +++++++++++++++++++
>> 2 files changed, 814 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>>
>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index ae002c7cf126..1cbc7b91389d 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -268,6 +268,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk-display-card.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += sm8650-hdk.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += sm8650-mtp.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += sm8650-qrd.dtb
>> +dtb-$(CONFIG_ARCH_QCOM) += x1e001de-devkit.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += x1e78100-lenovo-thinkpad-t14s.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += x1e80100-asus-vivobook-s15.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += x1e80100-crd.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>> new file mode 100644
>> index 000000000000..07b4e60d9b66
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>> @@ -0,0 +1,813 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>> +
>> +#include "x1e80100.dtsi"
>> +#include "x1e80100-pmics.dtsi"
>> +
>> +/ {
>> + model = "Qualcomm Technologies, Inc. X1E001DE Snapdragon Devkit for Windows";
>> + compatible = "qcom,x1e001de-devkit", "qcom,x1e001de", "qcom,x1e80100";
>> +
>> + aliases {
>> + serial0 = &uart21;
>> + };
>> +
>> + 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>;
>> +
>> + /* Back panel port closer to the RJ45 connector */
>> + connector@0 {
>> + compatible = "usb-c-connector";
>> + reg = <0>;
>> + power-role = "dual";
>> + data-role = "dual";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + pmic_glink_ss0_hs_in: endpoint {
>> + remote-endpoint = <&usb_1_ss0_dwc3_hs>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + pmic_glink_ss0_ss_in: endpoint {
>> + remote-endpoint = <&usb_1_ss0_qmpphy_out>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + /* Back panel port closer to the audio jack */
>> + 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 = <&usb_1_ss1_qmpphy_out>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + /* Front panel port */
>> + connector@2 {
>> + compatible = "usb-c-connector";
>> + reg = <2>;
>> + power-role = "dual";
>> + data-role = "dual";
>> +
>
> [trimmed]
>
>> +
>> +&pcie5 {
>> + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
>> + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
>> +
>> + vddpe-3v3-supply = <&vreg_wwan>;
>
> Please use pwrseq instead.
>
>> +
>> + pinctrl-0 = <&pcie5_default>;
>> + pinctrl-names = "default";
>> +
>> + status = "okay";
>> +};
>> +
>> +&pcie5_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>;
>> +
>> + vddpe-3v3-supply = <&vreg_nvme>;
>
> Please use pwrseq instead.
>
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie6a_default>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&pcie6a_phy {
>> + vdda-phy-supply = <&vreg_l1d_0p8>;
>> + vdda-pll-supply = <&vreg_l2j_1p2>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&qupv3_0 {
>> + status = "okay";
>> +};
>> +
>> +&qupv3_1 {
>> + status = "okay";
>> +};
>> +
>> +&qupv3_2 {
>> + status = "okay";
>> +};
>> +
>> +&remoteproc_adsp {
>> + firmware-name = "qcom/x1e80100/devkit/qcadsp8380.mbn",
>> + "qcom/x1e80100/devkit/adsp_dtbs.elf";
>
> qcom/SoC/Vendor/Device/foo.ext. Here the Vendor part is missing.
>
>> +
>> + status = "okay";
>> +};
>> +
>> +&remoteproc_cdsp {
>> + firmware-name = "qcom/x1e80100/devkit/qccdsp8380.mbn",
>> + "qcom/x1e80100/devkit/cdsp_dtbs.elf";
>> +
>> + status = "okay";
>> +};
>> +
>> +&smb2360_0_eusb2_repeater {
>> + vdd18-supply = <&vreg_l3d_1p8>;
>> + vdd3-supply = <&vreg_l2b_3p0>;
>> +};
>> +
>> +&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 {
>> + gpio-reserved-ranges = <34 2>, /* Unused */
>> + <44 4>, /* SPI (TPM) */
>> + <238 1>; /* UFS Reset */
>
> A comment would be nice. Usually the GPIOs are reserved because
> accessing them is forbidden by TZ / hyp. Is this the case for the Unused
> GPIOs? And why is the UFS reset marked as reserved?
I went back and figured out that 34,35 and 238 are no longer reserved.
It might be the case for other devices as well. I'll fix that.
>
>> +
>> + nvme_reg_en: nvme-reg-en-state {
>> + pins = "gpio18";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + 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;
>> + };
>> + };
>> +
>> + pcie5_default: pcie5-default-state {
>> + clkreq-n-pins {
>> + pins = "gpio150";
>> + function = "pcie5_clk";
>> + drive-strength = <2>;
>> + bias-pull-up;
>> + };
>> +
>> + perst-n-pins {
>> + pins = "gpio149";
>> + function = "gpio";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + wake-n-pins {
>> + pins = "gpio151";
>> + 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;
>> + };
>> + };
>> +
>> + wwan_sw_en: wwan-sw-en-state {
>> + pins = "gpio221";
>> + function = "gpio";
>> + drive-strength = <4>;
>> + bias-disable;
>> + };
>> +};
>> +
>> +&uart21 {
>> + compatible = "qcom,geni-debug-uart";
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss0_hsphy {
>> + vdd-supply = <&vreg_l3j_0p8>;
>> + vdda12-supply = <&vreg_l2j_1p2>;
>> +
>> + phys = <&smb2360_0_eusb2_repeater>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss0_qmpphy {
>> + vdda-phy-supply = <&vreg_l3e_1p2>;
>> + vdda-pll-supply = <&vreg_l1j_0p8>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss0 {
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss0_dwc3 {
>> + dr_mode = "host";
>> +};
>> +
>> +&usb_1_ss0_dwc3_hs {
>> + remote-endpoint = <&pmic_glink_ss0_hs_in>;
>> +};
>> +
>> +&usb_1_ss0_qmpphy_out {
>> + remote-endpoint = <&pmic_glink_ss0_ss_in>;
>> +};
>> +
>> +&usb_1_ss1_hsphy {
>> + vdd-supply = <&vreg_l3j_0p8>;
>> + vdda12-supply = <&vreg_l2j_1p2>;
>> +
>> + phys = <&smb2360_1_eusb2_repeater>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss1_qmpphy {
>> + vdda-phy-supply = <&vreg_l3e_1p2>;
>> + vdda-pll-supply = <&vreg_l2d_0p9>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss1 {
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss1_dwc3 {
>> + dr_mode = "host";
>
> All three USB-C connectors have data-role set to "dual". So this needs a
> comment.
Docs show that only port0 supports DRD. Will fix it in v2.
-Sibi
>
>> +};
>> +
>> +&usb_1_ss1_dwc3_hs {
>> + remote-endpoint = <&pmic_glink_ss1_hs_in>;
>> +};
>> +
>> +&usb_1_ss1_qmpphy_out {
>> + remote-endpoint = <&pmic_glink_ss1_ss_in>;
>> +};
>> +
>> +&usb_1_ss2_hsphy {
>> + vdd-supply = <&vreg_l3j_0p8>;
>> + vdda12-supply = <&vreg_l2j_1p2>;
>> +
>> + phys = <&smb2360_2_eusb2_repeater>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss2_qmpphy {
>> + vdda-phy-supply = <&vreg_l3e_1p2>;
>> + vdda-pll-supply = <&vreg_l2d_0p9>;
>> +
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss2 {
>> + status = "okay";
>> +};
>> +
>> +&usb_1_ss2_dwc3 {
>> + dr_mode = "host";
>> +};
>> +
>> +&usb_1_ss2_dwc3_hs {
>> + remote-endpoint = <&pmic_glink_ss2_hs_in>;
>> +};
>> +
>> +&usb_1_ss2_qmpphy_out {
>> + remote-endpoint = <&pmic_glink_ss2_ss_in>;
>> +};
>> --
>> 2.34.1
>>
>
On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
[..]
> > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
[..]
> > +
> > +&pcie5 {
> > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > +
> > + vddpe-3v3-supply = <&vreg_wwan>;
>
> Please use pwrseq instead.
>
What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > +
> > + pinctrl-0 = <&pcie5_default>;
> > + pinctrl-names = "default";
> > +
> > + status = "okay";
> > +};
> > +
> > +&pcie5_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>;
> > +
> > + vddpe-3v3-supply = <&vreg_nvme>;
>
> Please use pwrseq instead.
>
Ditto
Regards,
Bjorn
On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
>On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
>> On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
>[..]
>> > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>[..]
>> > +
>> > +&pcie5 {
>> > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
>> > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
>> > +
>> > + vddpe-3v3-supply = <&vreg_wwan>;
>>
>> Please use pwrseq instead.
>>
>
>What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
>
>> > +
>> > + pinctrl-0 = <&pcie5_default>;
>> > + pinctrl-names = "default";
>> > +
>> > + status = "okay";
>> > +};
>> > +
>> > +&pcie5_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>;
>> > +
>> > + vddpe-3v3-supply = <&vreg_nvme>;
>>
>> Please use pwrseq instead.
>>
>
>Ditto
Same set of questions.
>
>Regards,
>Bjorn
--
With best wishes
Dmitry
On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> >On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> >> On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> >[..]
> >> > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> >[..]
> >> > +
> >> > +&pcie5 {
> >> > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> >> > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> >> > +
> >> > + vddpe-3v3-supply = <&vreg_wwan>;
> >>
> >> Please use pwrseq instead.
> >>
> >
> >What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
>
> First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
>
Yeah, we should get into the details here. We were not paying attention till
now, but with the advent of pwrseq, we should describe the power supply properly
in DT.
Here I believe the supply is to the PCIe Mini Card connector where a modem is
connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
connector and we should have a generic pwrseq driver for the mini cards.
Sibi, please verify the above in schematics.
- Mani
--
மணிவண்ணன் சதாசிவம்
On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
>> On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
>>> On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
>>>> On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
>>> [..]
>>>>> diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
>>> [..]
>>>>> +
>>>>> +&pcie5 {
>>>>> + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
>>>>> + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
>>>>> +
>>>>> + vddpe-3v3-supply = <&vreg_wwan>;
>>>>
>>>> Please use pwrseq instead.
>>>>
>>>
>>> What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
>>
>> First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
>>
>
> Yeah, we should get into the details here. We were not paying attention till
> now, but with the advent of pwrseq, we should describe the power supply properly
> in DT.
>
> Here I believe the supply is to the PCIe Mini Card connector where a modem is
> connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> connector and we should have a generic pwrseq driver for the mini cards.
>
Hey Mani, Dmitry,
The schematics are identical to that of the X1E CRD with
the exception of the pcie daughter card having the rtl8125g
on it. Yes, the 3.3V supply is connected to the card as well.
Doesn't this mean all other x1e boards out there needs to be
updated with pwrseq as well? Anway will get that addressed in
v3.
-Sibi
> Sibi, please verify the above in schematics.
>
> - Mani
On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
>
>
> On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > [..]
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > [..]
> > > > > > +
> > > > > > +&pcie5 {
> > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > +
> > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > >
> > > > > Please use pwrseq instead.
> > > > >
> > > >
> > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > >
> > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > >
> >
> > Yeah, we should get into the details here. We were not paying attention till
> > now, but with the advent of pwrseq, we should describe the power supply properly
> > in DT.
> >
> > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > connector and we should have a generic pwrseq driver for the mini cards.
> >
>
> Hey Mani, Dmitry,
>
> The schematics are identical to that of the X1E CRD with
> the exception of the pcie daughter card having the rtl8125g
> on it. Yes, the 3.3V supply is connected to the card as well.
>
Is this connected to the 3.3vaux of the card? Please specify the actual rail
name as the 'PCI Express Mini Card Electromechanical Specification' specifies
only 3.3Vaux and 1.5v supplies.
> Doesn't this mean all other x1e boards out there needs to be
> updated with pwrseq as well? Anway will get that addressed in
> v3.
>
pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
use of pwrseq, the supplies need to be described in the proper place. In this
case most likely under a separate node of PCIe bridge. Then you'd need a
separate pwrseq driver in kernel to parse the supply and take care of it.
I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
be able to post it early next week. So you or someone could use it as a
reference to add a new driver for m-pcie cards.
If no one picks it up, I may just do it.
- Mani
--
மணிவண்ணன் சதாசிவம்
On Sun, Oct 06, 2024 at 11:31:52PM +0530, Manivannan Sadhasivam wrote:
> On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
> >
> >
> > On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > > [..]
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > > [..]
> > > > > > > +
> > > > > > > +&pcie5 {
> > > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > > +
> > > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > > >
> > > > > > Please use pwrseq instead.
> > > > > >
> > > > >
> > > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > > >
> > > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > > >
> > >
> > > Yeah, we should get into the details here. We were not paying attention till
> > > now, but with the advent of pwrseq, we should describe the power supply properly
> > > in DT.
> > >
> > > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > > connector and we should have a generic pwrseq driver for the mini cards.
> > >
> >
> > Hey Mani, Dmitry,
> >
> > The schematics are identical to that of the X1E CRD with
> > the exception of the pcie daughter card having the rtl8125g
> > on it. Yes, the 3.3V supply is connected to the card as well.
> >
>
> Is this connected to the 3.3vaux of the card? Please specify the actual rail
> name as the 'PCI Express Mini Card Electromechanical Specification' specifies
> only 3.3Vaux and 1.5v supplies.
>
> > Doesn't this mean all other x1e boards out there needs to be
> > updated with pwrseq as well? Anway will get that addressed in
> > v3.
> >
>
> pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
> use of pwrseq, the supplies need to be described in the proper place. In this
> case most likely under a separate node of PCIe bridge. Then you'd need a
> separate pwrseq driver in kernel to parse the supply and take care of it.
>
> I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
> be able to post it early next week. So you or someone could use it as a
> reference to add a new driver for m-pcie cards.
>
> If no one picks it up, I may just do it.
>
Hi,
The slot driver is taking more time than anticipated due to the pwrctl rework.
So please go ahead with the current binding and we would switch to pwrseq
later once the driver is available.
- Mani
--
மணிவண்ணன் சதாசிவம்
On Tue, 15 Oct 2024 at 16:51, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Sun, Oct 06, 2024 at 11:31:52PM +0530, Manivannan Sadhasivam wrote:
> > On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
> > >
> > >
> > > On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > > > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > > > [..]
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > > > [..]
> > > > > > > > +
> > > > > > > > +&pcie5 {
> > > > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > > > +
> > > > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > > > >
> > > > > > > Please use pwrseq instead.
> > > > > > >
> > > > > >
> > > > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > > > >
> > > > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > > > >
> > > >
> > > > Yeah, we should get into the details here. We were not paying attention till
> > > > now, but with the advent of pwrseq, we should describe the power supply properly
> > > > in DT.
> > > >
> > > > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > > > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > > > connector and we should have a generic pwrseq driver for the mini cards.
> > > >
> > >
> > > Hey Mani, Dmitry,
> > >
> > > The schematics are identical to that of the X1E CRD with
> > > the exception of the pcie daughter card having the rtl8125g
> > > on it. Yes, the 3.3V supply is connected to the card as well.
> > >
> >
> > Is this connected to the 3.3vaux of the card? Please specify the actual rail
> > name as the 'PCI Express Mini Card Electromechanical Specification' specifies
> > only 3.3Vaux and 1.5v supplies.
> >
> > > Doesn't this mean all other x1e boards out there needs to be
> > > updated with pwrseq as well? Anway will get that addressed in
> > > v3.
> > >
> >
> > pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
> > use of pwrseq, the supplies need to be described in the proper place. In this
> > case most likely under a separate node of PCIe bridge. Then you'd need a
> > separate pwrseq driver in kernel to parse the supply and take care of it.
> >
> > I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
> > be able to post it early next week. So you or someone could use it as a
> > reference to add a new driver for m-pcie cards.
> >
> > If no one picks it up, I may just do it.
> >
>
> Hi,
>
> The slot driver is taking more time than anticipated due to the pwrctl rework.
> So please go ahead with the current binding and we would switch to pwrseq
> later once the driver is available.
I assume this applies only to the case of the actual 3.3V being used
to power up the PCIe slot? Or to all existing pending items using
vddpe-3v3-supply?
--
With best wishes
Dmitry
On Tue, Oct 15, 2024 at 04:57:45PM +0300, Dmitry Baryshkov wrote:
> On Tue, 15 Oct 2024 at 16:51, Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> wrote:
> >
> > On Sun, Oct 06, 2024 at 11:31:52PM +0530, Manivannan Sadhasivam wrote:
> > > On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
> > > >
> > > >
> > > > On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > > > > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > > > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > > > > [..]
> > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > > > > [..]
> > > > > > > > > +
> > > > > > > > > +&pcie5 {
> > > > > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > > > > +
> > > > > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > > > > >
> > > > > > > > Please use pwrseq instead.
> > > > > > > >
> > > > > > >
> > > > > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > > > > >
> > > > > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > > > > >
> > > > >
> > > > > Yeah, we should get into the details here. We were not paying attention till
> > > > > now, but with the advent of pwrseq, we should describe the power supply properly
> > > > > in DT.
> > > > >
> > > > > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > > > > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > > > > connector and we should have a generic pwrseq driver for the mini cards.
> > > > >
> > > >
> > > > Hey Mani, Dmitry,
> > > >
> > > > The schematics are identical to that of the X1E CRD with
> > > > the exception of the pcie daughter card having the rtl8125g
> > > > on it. Yes, the 3.3V supply is connected to the card as well.
> > > >
> > >
> > > Is this connected to the 3.3vaux of the card? Please specify the actual rail
> > > name as the 'PCI Express Mini Card Electromechanical Specification' specifies
> > > only 3.3Vaux and 1.5v supplies.
> > >
> > > > Doesn't this mean all other x1e boards out there needs to be
> > > > updated with pwrseq as well? Anway will get that addressed in
> > > > v3.
> > > >
> > >
> > > pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
> > > use of pwrseq, the supplies need to be described in the proper place. In this
> > > case most likely under a separate node of PCIe bridge. Then you'd need a
> > > separate pwrseq driver in kernel to parse the supply and take care of it.
> > >
> > > I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
> > > be able to post it early next week. So you or someone could use it as a
> > > reference to add a new driver for m-pcie cards.
> > >
> > > If no one picks it up, I may just do it.
> > >
> >
> > Hi,
> >
> > The slot driver is taking more time than anticipated due to the pwrctl rework.
> > So please go ahead with the current binding and we would switch to pwrseq
> > later once the driver is available.
>
> I assume this applies only to the case of the actual 3.3V being used
> to power up the PCIe slot? Or to all existing pending items using
> vddpe-3v3-supply?
>
What do you mean by 'pending items using vddpe-3v3-supply'? I was referring to
the slot supplies only.
- Mani
--
மணிவண்ணன் சதாசிவம்
On Tue, Oct 15, 2024 at 08:57:36PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Oct 15, 2024 at 04:57:45PM +0300, Dmitry Baryshkov wrote:
> > On Tue, 15 Oct 2024 at 16:51, Manivannan Sadhasivam
> > <manivannan.sadhasivam@linaro.org> wrote:
> > >
> > > On Sun, Oct 06, 2024 at 11:31:52PM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Oct 06, 2024 at 12:33:21AM +0530, Sibi Sankar wrote:
> > > > >
> > > > >
> > > > > On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > > > > > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > > > > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > > > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > > > > > [..]
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > > > > > [..]
> > > > > > > > > > +
> > > > > > > > > > +&pcie5 {
> > > > > > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > > > > > +
> > > > > > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > > > > > >
> > > > > > > > > Please use pwrseq instead.
> > > > > > > > >
> > > > > > > >
> > > > > > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > > > > > >
> > > > > > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > > > > > >
> > > > > >
> > > > > > Yeah, we should get into the details here. We were not paying attention till
> > > > > > now, but with the advent of pwrseq, we should describe the power supply properly
> > > > > > in DT.
> > > > > >
> > > > > > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > > > > > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > > > > > connector and we should have a generic pwrseq driver for the mini cards.
> > > > > >
> > > > >
> > > > > Hey Mani, Dmitry,
> > > > >
> > > > > The schematics are identical to that of the X1E CRD with
> > > > > the exception of the pcie daughter card having the rtl8125g
> > > > > on it. Yes, the 3.3V supply is connected to the card as well.
> > > > >
> > > >
> > > > Is this connected to the 3.3vaux of the card? Please specify the actual rail
> > > > name as the 'PCI Express Mini Card Electromechanical Specification' specifies
> > > > only 3.3Vaux and 1.5v supplies.
> > > >
> > > > > Doesn't this mean all other x1e boards out there needs to be
> > > > > updated with pwrseq as well? Anway will get that addressed in
> > > > > v3.
> > > > >
> > > >
> > > > pwrseq is the kernel driver abstraction, nothing to do with DT. But for making
> > > > use of pwrseq, the supplies need to be described in the proper place. In this
> > > > case most likely under a separate node of PCIe bridge. Then you'd need a
> > > > separate pwrseq driver in kernel to parse the supply and take care of it.
> > > >
> > > > I'm currently writing a pwrseq driver for standard slots (x8 for X1E) and should
> > > > be able to post it early next week. So you or someone could use it as a
> > > > reference to add a new driver for m-pcie cards.
> > > >
> > > > If no one picks it up, I may just do it.
> > > >
> > >
> > > Hi,
> > >
> > > The slot driver is taking more time than anticipated due to the pwrctl rework.
> > > So please go ahead with the current binding and we would switch to pwrseq
> > > later once the driver is available.
> >
> > I assume this applies only to the case of the actual 3.3V being used
> > to power up the PCIe slot? Or to all existing pending items using
> > vddpe-3v3-supply?
> >
>
> What do you mean by 'pending items using vddpe-3v3-supply'? I was referring to
> the slot supplies only.
As we've checked offline, it seems to be just a controlled 3.3V supply
for both NVMe and WWAN. I'm fine with using vddpe-3v3-supply.
--
With best wishes
Dmitry
On Sun, Oct 06, 2024 at 12:33:21AM GMT, Sibi Sankar wrote:
>
>
> On 10/1/24 14:21, Manivannan Sadhasivam wrote:
> > On Tue, Oct 01, 2024 at 09:56:30AM +0300, Dmitry Baryshkov wrote:
> > > On October 1, 2024 5:42:35 AM GMT+03:00, Bjorn Andersson <andersson@kernel.org> wrote:
> > > > On Wed, Sep 11, 2024 at 10:55:05AM GMT, Dmitry Baryshkov wrote:
> > > > > On Wed, Sep 11, 2024 at 01:03:37PM GMT, Sibi Sankar wrote:
> > > > [..]
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> > > > [..]
> > > > > > +
> > > > > > +&pcie5 {
> > > > > > + perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> > > > > > + wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> > > > > > +
> > > > > > + vddpe-3v3-supply = <&vreg_wwan>;
> > > > >
> > > > > Please use pwrseq instead.
> > > > >
> > > >
> > > > What benefit is there to wrap a single 3.3V regulator in pwrseq driver?
> > >
> > > First of all, is it really just a 3.3V? Second, is it actually powering up the host controller (as expressed in the device tree? Is it a power supply to the slot (in this case, I think, it should be expressed differently)? Or is it a power supply to the card itself?
> > >
> >
> > Yeah, we should get into the details here. We were not paying attention till
> > now, but with the advent of pwrseq, we should describe the power supply properly
> > in DT.
> >
> > Here I believe the supply is to the PCIe Mini Card connector where a modem is
> > connected. In that case, 3.3v supply should be connected to 3.3Vaux of the
> > connector and we should have a generic pwrseq driver for the mini cards.
> >
>
> Hey Mani, Dmitry,
>
> The schematics are identical to that of the X1E CRD with
> the exception of the pcie daughter card having the rtl8125g
> on it. Yes, the 3.3V supply is connected to the card as well.
>
> Doesn't this mean all other x1e boards out there needs to be
> updated with pwrseq as well? Anway will get that addressed in
> v3.
Yes please. Check with Bartosz and Johan if they are working on pwrseq
for this platform by chance.
>
> -Sibi
>
> > Sibi, please verify the above in schematics.
> >
> > - Mani
--
With best wishes
Dmitry
© 2016 - 2024 Red Hat, Inc.