| Message ID | 20240905122023.47251-2-brgl@bgdev.pl (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: dts: qcom: sc8280xp: enable WLAN and Bluetooth | expand |
On Thu, Sep 05, 2024 at 02:20:19PM GMT, Bartosz Golaszewski wrote: > From: Konrad Dybcio <konradybcio@kernel.org> > > Add nodes for the WCN6855 PMU, the WLAN module and relevant regulators > and pin functions to fully describe how the wifi is actually wired on > this platform. > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Konrad Dybcio <konradybcio@kernel.org> > [Bartosz: > - write the commit message, > - rebase Konrad's commit, > - fix one of the supplies' name] > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++ > 1 file changed, 108 insertions(+) > > @@ -583,6 +668,23 @@ &pcie4_phy { > status = "okay"; > }; > > +&pcie4_port0 { > + wifi@0 { > + compatible = "pci17cb,1103"; > + reg = <0x10000 0x0 0x0 0x0 0x0>; > + > + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>; > + vddaon-supply = <&vreg_pmu_aon_0p8>; > + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; > + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>; > + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; > + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; > + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; > + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; > + vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; As you are going to post another revision, please also add qcom,ath11k-calibration-variant > + }; > +}; > + > &pmc8280c_lpg { > status = "okay"; > };
On Thu, Sep 5, 2024 at 2:50 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > On Thu, Sep 05, 2024 at 02:20:19PM GMT, Bartosz Golaszewski wrote: > > From: Konrad Dybcio <konradybcio@kernel.org> > > > > Add nodes for the WCN6855 PMU, the WLAN module and relevant regulators > > and pin functions to fully describe how the wifi is actually wired on > > this platform. > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Signed-off-by: Konrad Dybcio <konradybcio@kernel.org> > > [Bartosz: > > - write the commit message, > > - rebase Konrad's commit, > > - fix one of the supplies' name] > > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > --- > > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++ > > 1 file changed, 108 insertions(+) > > > > @@ -583,6 +668,23 @@ &pcie4_phy { > > status = "okay"; > > }; > > > > +&pcie4_port0 { > > + wifi@0 { > > + compatible = "pci17cb,1103"; > > + reg = <0x10000 0x0 0x0 0x0 0x0>; > > + > > + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>; > > + vddaon-supply = <&vreg_pmu_aon_0p8>; > > + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; > > + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>; > > + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; > > + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; > > + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; > > + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; > > + vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; > > As you are going to post another revision, please also add > > qcom,ath11k-calibration-variant > I had it in earlier revisions. The only one we could add here would be the one from X13s as QCom has not yet released the data for the CRD. Johan and Konrad were against adding this here if it doesn't refer to the correct one so I dropped it. Bart > > + }; > > +}; > > + > > &pmc8280c_lpg { > > status = "okay"; > > }; > > -- > With best wishes > Dmitry
On Thu, 5 Sept 2024 at 15:53, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Thu, Sep 5, 2024 at 2:50 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > > > On Thu, Sep 05, 2024 at 02:20:19PM GMT, Bartosz Golaszewski wrote: > > > From: Konrad Dybcio <konradybcio@kernel.org> > > > > > > Add nodes for the WCN6855 PMU, the WLAN module and relevant regulators > > > and pin functions to fully describe how the wifi is actually wired on > > > this platform. > > > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > > Signed-off-by: Konrad Dybcio <konradybcio@kernel.org> > > > [Bartosz: > > > - write the commit message, > > > - rebase Konrad's commit, > > > - fix one of the supplies' name] > > > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > --- > > > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++ > > > 1 file changed, 108 insertions(+) > > > > > > @@ -583,6 +668,23 @@ &pcie4_phy { > > > status = "okay"; > > > }; > > > > > > +&pcie4_port0 { > > > + wifi@0 { > > > + compatible = "pci17cb,1103"; > > > + reg = <0x10000 0x0 0x0 0x0 0x0>; > > > + > > > + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>; > > > + vddaon-supply = <&vreg_pmu_aon_0p8>; > > > + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; > > > + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>; > > > + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; > > > + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; > > > + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; > > > + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; > > > + vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; > > > > As you are going to post another revision, please also add > > > > qcom,ath11k-calibration-variant > > > > I had it in earlier revisions. The only one we could add here would be > the one from X13s as QCom has not yet released the data for the CRD. > Johan and Konrad were against adding this here if it doesn't refer to > the correct one so I dropped it. As Kalle usually merges data with some delay it's not infrequent to have DTS which names calibration variant, but board-2.bin doesn't have corresponding data. The driver safely falls back to the data without variant if it can find it. Als usually it's us who supply the calibration name. > > Bart > > > > + }; > > > +}; > > > + > > > &pmc8280c_lpg { > > > status = "okay"; > > > }; > > > > -- > > With best wishes > > Dmitry
On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > > > > > > As you are going to post another revision, please also add > > > > > > qcom,ath11k-calibration-variant > > > > > > > I had it in earlier revisions. The only one we could add here would be > > the one from X13s as QCom has not yet released the data for the CRD. > > Johan and Konrad were against adding this here if it doesn't refer to > > the correct one so I dropped it. > > As Kalle usually merges data with some delay it's not infrequent to > have DTS which names calibration variant, but board-2.bin doesn't have > corresponding data. The driver safely falls back to the data without > variant if it can find it. Als usually it's us who supply the > calibration name. > Johan, Konrad, What do you think? Do we know the exact name and should I add it or should we wait until it's in board-2.bin? Bart
On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: > On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: >> >>>> >>>> As you are going to post another revision, please also add >>>> >>>> qcom,ath11k-calibration-variant >>>> >>> >>> I had it in earlier revisions. The only one we could add here would be >>> the one from X13s as QCom has not yet released the data for the CRD. >>> Johan and Konrad were against adding this here if it doesn't refer to >>> the correct one so I dropped it. >> >> As Kalle usually merges data with some delay it's not infrequent to >> have DTS which names calibration variant, but board-2.bin doesn't have >> corresponding data. The driver safely falls back to the data without >> variant if it can find it. Als usually it's us who supply the >> calibration name. >> > > Johan, Konrad, > > What do you think? Do we know the exact name and should I add it or > should we wait until it's in board-2.bin? If we can agree on the string identifier with Kalle in advance, we can add it even before the boardfile drops Konrad
Konrad Dybcio <konradybcio@kernel.org> writes: > On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: >> On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: >>> >>>>> >>>>> As you are going to post another revision, please also add >>>>> >>>>> qcom,ath11k-calibration-variant >>>>> >>>> >>>> I had it in earlier revisions. The only one we could add here would be >>>> the one from X13s as QCom has not yet released the data for the CRD. >>>> Johan and Konrad were against adding this here if it doesn't refer to >>>> the correct one so I dropped it. >>> >>> As Kalle usually merges data with some delay it's not infrequent to >>> have DTS which names calibration variant, but board-2.bin doesn't have >>> corresponding data. The driver safely falls back to the data without >>> variant if it can find it. Als usually it's us who supply the >>> calibration name. >>> >> >> Johan, Konrad, >> >> What do you think? Do we know the exact name and should I add it or >> should we wait until it's in board-2.bin? > > If we can agree on the string identifier with Kalle in advance, we can > add it even before the boardfile drops There have not been really any naming rules for the variant string, it just needs to be unique so that it doesn't conflict with other variant strings. What have you been thinking? But please Cc the ath11k list for anything ath11k related, adding it now.
On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > Konrad Dybcio <konradybcio@kernel.org> writes: > > > On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: > >> On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > >>> > >>>>> > >>>>> As you are going to post another revision, please also add > >>>>> > >>>>> qcom,ath11k-calibration-variant > >>>>> > >>>> > >>>> I had it in earlier revisions. The only one we could add here would be > >>>> the one from X13s as QCom has not yet released the data for the CRD. > >>>> Johan and Konrad were against adding this here if it doesn't refer to > >>>> the correct one so I dropped it. > >>> > >>> As Kalle usually merges data with some delay it's not infrequent to > >>> have DTS which names calibration variant, but board-2.bin doesn't have > >>> corresponding data. The driver safely falls back to the data without > >>> variant if it can find it. Als usually it's us who supply the > >>> calibration name. > >>> > >> > >> Johan, Konrad, > >> > >> What do you think? Do we know the exact name and should I add it or > >> should we wait until it's in board-2.bin? > > > > If we can agree on the string identifier with Kalle in advance, we can > > add it even before the boardfile drops > > There have not been really any naming rules for the variant string, it > just needs to be unique so that it doesn't conflict with other variant > strings. What have you been thinking? QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following marketing name). Or maybe QTI_ instead of QC_. WDYT? > > But please Cc the ath11k list for anything ath11k related, adding it > now. > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Thu, Sep 5, 2024 at 9:26 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > > Konrad Dybcio <konradybcio@kernel.org> writes: > > > > > On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: > > >> On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > >>> > > >>>>> > > >>>>> As you are going to post another revision, please also add > > >>>>> > > >>>>> qcom,ath11k-calibration-variant > > >>>>> > > >>>> > > >>>> I had it in earlier revisions. The only one we could add here would be > > >>>> the one from X13s as QCom has not yet released the data for the CRD. > > >>>> Johan and Konrad were against adding this here if it doesn't refer to > > >>>> the correct one so I dropped it. > > >>> > > >>> As Kalle usually merges data with some delay it's not infrequent to > > >>> have DTS which names calibration variant, but board-2.bin doesn't have > > >>> corresponding data. The driver safely falls back to the data without > > >>> variant if it can find it. Als usually it's us who supply the > > >>> calibration name. > > >>> > > >> > > >> Johan, Konrad, > > >> > > >> What do you think? Do we know the exact name and should I add it or > > >> should we wait until it's in board-2.bin? > > > > > > If we can agree on the string identifier with Kalle in advance, we can > > > add it even before the boardfile drops > > > > There have not been really any naming rules for the variant string, it > > just needs to be unique so that it doesn't conflict with other variant > > strings. What have you been thinking? > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following > marketing name). Or maybe QTI_ instead of QC_. WDYT? > Is there any central authority listing these names? Or are they just agreed upon on the mailing list? I honestly don't know where they come from. Bart
On Fri, 6 Sept 2024 at 10:45, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Thu, Sep 5, 2024 at 9:26 PM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > > > > On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > > > Konrad Dybcio <konradybcio@kernel.org> writes: > > > > > > > On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: > > > >> On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > > >>> > > > >>>>> > > > >>>>> As you are going to post another revision, please also add > > > >>>>> > > > >>>>> qcom,ath11k-calibration-variant > > > >>>>> > > > >>>> > > > >>>> I had it in earlier revisions. The only one we could add here would be > > > >>>> the one from X13s as QCom has not yet released the data for the CRD. > > > >>>> Johan and Konrad were against adding this here if it doesn't refer to > > > >>>> the correct one so I dropped it. > > > >>> > > > >>> As Kalle usually merges data with some delay it's not infrequent to > > > >>> have DTS which names calibration variant, but board-2.bin doesn't have > > > >>> corresponding data. The driver safely falls back to the data without > > > >>> variant if it can find it. Als usually it's us who supply the > > > >>> calibration name. > > > >>> > > > >> > > > >> Johan, Konrad, > > > >> > > > >> What do you think? Do we know the exact name and should I add it or > > > >> should we wait until it's in board-2.bin? > > > > > > > > If we can agree on the string identifier with Kalle in advance, we can > > > > add it even before the boardfile drops > > > > > > There have not been really any naming rules for the variant string, it > > > just needs to be unique so that it doesn't conflict with other variant > > > strings. What have you been thinking? > > > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following > > marketing name). Or maybe QTI_ instead of QC_. WDYT? > > > > Is there any central authority listing these names? Or are they just > agreed upon on the mailing list? I honestly don't know where they come > from. I think on ath12k these names come from ACPI tables. On all previous devices it is just being agreed upon. Kalle is the central authority.
On Fri, Sep 6, 2024 at 11:37 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Fri, 6 Sept 2024 at 10:45, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Thu, Sep 5, 2024 at 9:26 PM Dmitry Baryshkov > > <dmitry.baryshkov@linaro.org> wrote: > > > > > > On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > > > > Konrad Dybcio <konradybcio@kernel.org> writes: > > > > > > > > > On 5.09.2024 3:00 PM, Bartosz Golaszewski wrote: > > > > >> On Thu, Sep 5, 2024 at 2:56 PM Dmitry Baryshkov <dbaryshkov@gmail.com> wrote: > > > > >>> > > > > >>>>> > > > > >>>>> As you are going to post another revision, please also add > > > > >>>>> > > > > >>>>> qcom,ath11k-calibration-variant > > > > >>>>> > > > > >>>> > > > > >>>> I had it in earlier revisions. The only one we could add here would be > > > > >>>> the one from X13s as QCom has not yet released the data for the CRD. > > > > >>>> Johan and Konrad were against adding this here if it doesn't refer to > > > > >>>> the correct one so I dropped it. > > > > >>> > > > > >>> As Kalle usually merges data with some delay it's not infrequent to > > > > >>> have DTS which names calibration variant, but board-2.bin doesn't have > > > > >>> corresponding data. The driver safely falls back to the data without > > > > >>> variant if it can find it. Als usually it's us who supply the > > > > >>> calibration name. > > > > >>> > > > > >> > > > > >> Johan, Konrad, > > > > >> > > > > >> What do you think? Do we know the exact name and should I add it or > > > > >> should we wait until it's in board-2.bin? > > > > > > > > > > If we can agree on the string identifier with Kalle in advance, we can > > > > > add it even before the boardfile drops > > > > > > > > There have not been really any naming rules for the variant string, it > > > > just needs to be unique so that it doesn't conflict with other variant > > > > strings. What have you been thinking? > > > > > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following > > > marketing name). Or maybe QTI_ instead of QC_. WDYT? > > > > > > > Is there any central authority listing these names? Or are they just > > agreed upon on the mailing list? I honestly don't know where they come > > from. > > I think on ath12k these names come from ACPI tables. On all previous > devices it is just being agreed upon. Kalle is the central authority. > Kalle: is "QC_8280XP_CRD" fine for you for a board called sc8280xp-crd? Bart
On Thu, Sep 05, 2024 at 10:26:04PM +0300, Dmitry Baryshkov wrote: > On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > > There have not been really any naming rules for the variant string, it > > just needs to be unique so that it doesn't conflict with other variant > > strings. What have you been thinking? > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following > marketing name). Or maybe QTI_ instead of QC_. WDYT? The x1e80100 uses ath12k and the calibration data was recently pushed to linux firmware (and does not use a calibration variant). This thread is about sc8280xp and ath11k as I guess you've noticed by now. Johan
On Fri, Sep 06, 2024 at 04:53:07PM GMT, Johan Hovold wrote: > On Thu, Sep 05, 2024 at 10:26:04PM +0300, Dmitry Baryshkov wrote: > > On Thu, Sep 05, 2024 at 09:41:44PM GMT, Kalle Valo wrote: > > > > There have not been really any naming rules for the variant string, it > > > just needs to be unique so that it doesn't conflict with other variant > > > strings. What have you been thinking? > > > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following > > marketing name). Or maybe QTI_ instead of QC_. WDYT? > > The x1e80100 uses ath12k and the calibration data was recently pushed to > linux firmware (and does not use a calibration variant). > > This thread is about sc8280xp and ath11k as I guess you've noticed by > now. Yes, I'm sorry for the possible confusion caused.
Bartosz Golaszewski <brgl@bgdev.pl> writes: > On Fri, Sep 6, 2024 at 11:37 AM Dmitry Baryshkov > <dmitry.baryshkov@linaro.org> wrote: > >> >> On Fri, 6 Sept 2024 at 10:45, Bartosz Golaszewski <brgl@bgdev.pl> wrote: >> > >> > On Thu, Sep 5, 2024 at 9:26 PM Dmitry Baryshkov >> > <dmitry.baryshkov@linaro.org> wrote: >> > > >> > > QC_8380_CRD (following DMI / Windows name) or QC_X1E80100_CRD (following >> > > marketing name). Or maybe QTI_ instead of QC_. WDYT? >> > > >> > >> > Is there any central authority listing these names? Or are they just >> > agreed upon on the mailing list? I honestly don't know where they come >> > from. >> >> I think on ath12k these names come from ACPI tables. On all previous >> devices it is just being agreed upon. Kalle is the central authority. >> > > Kalle: is "QC_8280XP_CRD" fine for you for a board called sc8280xp-crd? Yes.
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts index 6020582b0a59..1f533c0d49ea 100644 --- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts @@ -177,6 +177,17 @@ vreg_misc_3p3: regulator-misc-3p3 { regulator-always-on; }; + vreg_s10b: regulator-s10b { + compatible = "regulator-fixed"; + + regulator-name = "VREG_S10B"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-always-on; + regulator-boot-on; + }; + vreg_wlan: regulator-wlan { compatible = "regulator-fixed"; @@ -260,6 +271,66 @@ usb1_sbu_mux: endpoint { }; }; }; + + wcn6855-pmu { + compatible = "qcom,wcn6855-pmu"; + + pinctrl-0 = <&wlan_en>; + pinctrl-names = "default"; + + wlan-enable-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>; + + vddio-supply = <&vreg_s10b>; + vddaon-supply = <&vreg_s12b>; + vddpmu-supply = <&vreg_s12b>; + vddrfa0p95-supply = <&vreg_s12b>; + vddrfa1p3-supply = <&vreg_s11b>; + vddrfa1p9-supply = <&vreg_s1c>; + vddpcie1p3-supply = <&vreg_s11b>; + vddpcie1p9-supply = <&vreg_s1c>; + + regulators { + vreg_pmu_rfa_cmn_0p8: ldo0 { + regulator-name = "vreg_pmu_rfa_cmn_0p8"; + }; + + vreg_pmu_aon_0p8: ldo1 { + regulator-name = "vreg_pmu_aon_0p8"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p8: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p8"; + }; + + vreg_pmu_btcmx_0p8: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p8"; + }; + + vreg_pmu_pcie_1p8: ldo5 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + + vreg_pmu_pcie_0p9: ldo6 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_rfa_0p8: ldo7 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo8 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p7: ldo9 { + regulator-name = "vreg_pmu_rfa_1p7"; + }; + }; + }; }; &apps_rsc { @@ -276,6 +347,13 @@ vreg_s11b: smps11 { regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; }; + vreg_s12b: smps12 { + regulator-name = "vreg_s12b"; + regulator-min-microvolt = <984000>; + regulator-max-microvolt = <984000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + vreg_l3b: ldo3 { regulator-name = "vreg_l3b"; regulator-min-microvolt = <1200000>; @@ -304,6 +382,13 @@ regulators-1 { compatible = "qcom,pm8350c-rpmh-regulators"; qcom,pmic-id = "c"; + vreg_s1c: smps1 { + regulator-name = "vreg_s1c"; + regulator-min-microvolt = <1888000>; + regulator-max-microvolt = <1888000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + vreg_l1c: ldo1 { regulator-name = "vreg_l1c"; regulator-min-microvolt = <1800000>; @@ -583,6 +668,23 @@ &pcie4_phy { status = "okay"; }; +&pcie4_port0 { + wifi@0 { + compatible = "pci17cb,1103"; + reg = <0x10000 0x0 0x0 0x0 0x0>; + + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>; + vddaon-supply = <&vreg_pmu_aon_0p8>; + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>; + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; + }; +}; + &pmc8280c_lpg { status = "okay"; }; @@ -829,6 +931,12 @@ reset-pins { }; }; + wlan_en: wlan-en-state { + pins = "gpio134"; + function = "gpio"; + bias-pull-down; + }; + nvme_reg_en: nvme-reg-en-state { pins = "gpio135"; function = "gpio";