| Message ID | 20240911073337.90577-3-quic_sibis@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | X1E001DE Snapdragon Devkit for Windows | expand |
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 > > 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 >
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
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 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 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 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
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.
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>; +};
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