[PATCH v3 0/4] arm64: dts: qcom: sc8280xp: enable WLAN and Bluetooth

[PATCH v3 0/4] arm64: dts: qcom: sc8280xp: enable WLAN and Bluetooth

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

This correctly models the WLAN and Bluetooth modules on two boards using
the sc8280xp SoC. For the sc8280xp-crd we add the PMU, wifi and bluetooth
nodes with the correctly modelled wiring between them. For the X13s, we
rework existing nodes so that they align with the new DT bindings
contract.

v2 -> v3:
- move adding the bt-enable-gpios to the PMU on the CRD to patch 2/4
- add a patch removing the regulator-always-on property from regulators
  on X13s that no longer need it

v1 -> v2:
- fix commit message in patch 1/3
- drop drive-strength from the wlan enable pin function
- drop the calibration variant property from the wifi node of the CRD

Bartosz Golaszewski (3):
  arm64: dts: qcom: sc8280xp-crd: enable bluetooth
  arm64: dts: qcom: sc8280xp-x13s: model the PMU of the on-board wcn6855
  arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

Konrad Dybcio (1):
  arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts     | 166 ++++++++++++++++++
 .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 102 +++++++++--
 2 files changed, 252 insertions(+), 16 deletions(-)

-- 
2.43.0

[PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

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(+)

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";
-- 
2.43.0

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

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";
>  };

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

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



-- 
With best wishes
Dmitry

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Konrad Dybcio]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Kalle Valo]

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.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

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

-- 
With best wishes
Dmitry

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

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.


-- 
With best wishes
Dmitry

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Kalle Valo]

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.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Johan Hovold]

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

Re: [PATCH v3 1/4] arm64: dts: qcom: sc8280xp-crd: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

[PATCH v3 2/4] arm64: dts: qcom: sc8280xp-crd: enable bluetooth

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add the bluetooth node for sc8280xp-crd and make it consume the outputs
from the PMU as per the new DT bindings contract.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 60 ++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
index 1f533c0d49ea..eac3a6ce0b65 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
@@ -20,6 +20,7 @@ aliases {
 		i2c4 = &i2c4;
 		i2c21 = &i2c21;
 		serial0 = &uart17;
+		serial1 = &uart2;
 	};
 
 	backlight: backlight {
@@ -275,10 +276,11 @@ usb1_sbu_mux: endpoint {
 	wcn6855-pmu {
 		compatible = "qcom,wcn6855-pmu";
 
-		pinctrl-0 = <&wlan_en>;
+		pinctrl-0 = <&bt_en>, <&wlan_en>;
 		pinctrl-names = "default";
 
 		wlan-enable-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
 
 		vddio-supply = <&vreg_s10b>;
 		vddaon-supply = <&vreg_s12b>;
@@ -745,6 +747,27 @@ &sdc2 {
 	status = "okay";
 };
 
+&uart2 {
+	pinctrl-0 = <&uart2_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn6855-bt";
+
+		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>;
+		vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
+	};
+};
+
+
 &uart17 {
 	compatible = "qcom,geni-debug-uart";
 
@@ -890,6 +913,13 @@ hastings_reg_en: hastings-reg-en-state {
 &tlmm {
 	gpio-reserved-ranges = <74 6>, <83 4>, <125 2>, <128 2>, <154 7>;
 
+	bt_en: bt-en-state {
+		pins = "gpio133";
+		function = "gpio";
+		drive-strength = <16>;
+		bias-disable;
+	};
+
 	edp_reg_en: edp-reg-en-state {
 		pins = "gpio25";
 		function = "gpio";
@@ -1089,6 +1119,34 @@ reset-n-pins {
 		};
 	};
 
+	uart2_default: uart2-default-state {
+		cts-pins {
+			pins = "gpio121";
+			function = "qup2";
+			bias-bus-hold;
+		};
+
+		rts-pins {
+			pins = "gpio122";
+			function = "qup2";
+			drive-strength = <2>;
+			bias-disable;
+		};
+
+		rx-pins {
+			pins = "gpio124";
+			function = "qup2";
+			bias-pull-up;
+		};
+
+		tx-pins {
+			pins = "gpio123";
+			function = "qup2";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
 	usb0_sbu_default: usb0-sbu-state {
 		oe-n-pins {
 			pins = "gpio101";
-- 
2.43.0

[PATCH v3 3/4] arm64: dts: qcom: sc8280xp-x13s: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a node for the PMU of the WCN6855 and rework the inputs of the wifi
and bluetooth nodes to consume the PMU's outputs.

Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 98 ++++++++++++++++---
 1 file changed, 86 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 6a28cab97189..88b31550f9df 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -400,6 +400,67 @@ 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>;
+		bt-enable-gpios = <&tlmm 133 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 {
@@ -927,6 +988,16 @@ 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>;
+
 		qcom,ath11k-calibration-variant = "LE_X13S";
 	};
 };
@@ -1258,20 +1329,16 @@ &uart2 {
 	bluetooth {
 		compatible = "qcom,wcn6855-bt";
 
-		vddio-supply = <&vreg_s10b>;
-		vddbtcxmx-supply = <&vreg_s12b>;
-		vddrfacmn-supply = <&vreg_s12b>;
-		vddrfa0p8-supply = <&vreg_s12b>;
-		vddrfa1p2-supply = <&vreg_s11b>;
-		vddrfa1p7-supply = <&vreg_s1c>;
+		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>;
+		vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
 
 		max-speed = <3200000>;
-
-		enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
-		swctrl-gpios = <&tlmm 132 GPIO_ACTIVE_HIGH>;
-
-		pinctrl-0 = <&bt_default>;
-		pinctrl-names = "default";
 	};
 };
 
@@ -1761,4 +1828,11 @@ reset-pins {
 			bias-disable;
 		};
 	};
+
+	wlan_en: wlan-en-state {
+		pins = "gpio134";
+		function = "gpio";
+		drive-strength = <8>;
+		bias-pull-down;
+	};
 };
-- 
2.43.0

Re: [PATCH v3 3/4] arm64: dts: qcom: sc8280xp-x13s: model the PMU of the on-board wcn6855

[Dmitry Baryshkov]

On Thu, 5 Sept 2024 at 15:20, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Add a node for the PMU of the WCN6855 and rework the inputs of the wifi
> and bluetooth nodes to consume the PMU's outputs.
>
> Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 98 ++++++++++++++++---
>  1 file changed, 86 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index 6a28cab97189..88b31550f9df 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -400,6 +400,67 @@ usb1_sbu_mux: endpoint {
>                         };
>                 };
>         };
> +
> +       wcn6855-pmu {
> +               compatible = "qcom,wcn6855-pmu";
> +
> +               pinctrl-0 = <&wlan_en>;

pinctrl for the bt-enable pin?

> +               pinctrl-names = "default";
> +
> +               wlan-enable-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>;
> +               bt-enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
> +

-- 
With best wishes
Dmitry

Re: [PATCH v3 3/4] arm64: dts: qcom: sc8280xp-x13s: model the PMU of the on-board wcn6855

[Bartosz Golaszewski]

On Thu, Sep 5, 2024 at 2:27 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Thu, 5 Sept 2024 at 15:20, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Add a node for the PMU of the WCN6855 and rework the inputs of the wifi
> > and bluetooth nodes to consume the PMU's outputs.
> >
> > Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >  .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 98 ++++++++++++++++---
> >  1 file changed, 86 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > index 6a28cab97189..88b31550f9df 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > @@ -400,6 +400,67 @@ usb1_sbu_mux: endpoint {
> >                         };
> >                 };
> >         };
> > +
> > +       wcn6855-pmu {
> > +               compatible = "qcom,wcn6855-pmu";
> > +
> > +               pinctrl-0 = <&wlan_en>;
>
> pinctrl for the bt-enable pin?

Ah dammit. :(

I'll resend tomorrow to avoid spamming the list. Thanks.

Bart

[PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Remove the regulator-always-on property from the ones that used to be
implicitly needed by the on-board WCN6855 now that its PMU is modeled in
device-tree.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 88b31550f9df..1a9dac16c952 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -479,7 +479,6 @@ vreg_s10b: smps10 {
 			regulator-min-microvolt = <1800000>;
 			regulator-max-microvolt = <1800000>;
 			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
 		};
 
 		vreg_s11b: smps11 {
@@ -487,7 +486,6 @@ vreg_s11b: smps11 {
 			regulator-min-microvolt = <1272000>;
 			regulator-max-microvolt = <1272000>;
 			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
 		};
 
 		vreg_s12b: smps12 {
@@ -495,7 +493,6 @@ vreg_s12b: smps12 {
 			regulator-min-microvolt = <984000>;
 			regulator-max-microvolt = <984000>;
 			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
 		};
 
 		vreg_l1b: ldo1 {
@@ -545,7 +542,6 @@ vreg_s1c: smps1 {
 			regulator-min-microvolt = <1880000>;
 			regulator-max-microvolt = <1900000>;
 			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
-			regulator-always-on;
 		};
 
 		vreg_l1c: ldo1 {
-- 
2.43.0

Re: [PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Johan Hovold]

On Thu, Sep 05, 2024 at 02:20:22PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Remove the regulator-always-on property from the ones that used to be
> implicitly needed by the on-board WCN6855 now that its PMU is modeled in
> device-tree.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index 88b31550f9df..1a9dac16c952 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -479,7 +479,6 @@ vreg_s10b: smps10 {
>  			regulator-min-microvolt = <1800000>;
>  			regulator-max-microvolt = <1800000>;
>  			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> -			regulator-always-on;
>  		};

What makes you think s10b is only used by wcn6855?

You clearly did not check the schematics so make sure you verify the
rest as well before resending.

And if any of these are valid, I think this should be part of the
previous patch.

Johan

Re: [PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Bartosz Golaszewski]

On Thu, Sep 5, 2024 at 4:04 PM Johan Hovold <johan@kernel.org> wrote:
>
> On Thu, Sep 05, 2024 at 02:20:22PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Remove the regulator-always-on property from the ones that used to be
> > implicitly needed by the on-board WCN6855 now that its PMU is modeled in
> > device-tree.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > index 88b31550f9df..1a9dac16c952 100644
> > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > @@ -479,7 +479,6 @@ vreg_s10b: smps10 {
> >                       regulator-min-microvolt = <1800000>;
> >                       regulator-max-microvolt = <1800000>;
> >                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> > -                     regulator-always-on;
> >               };
>
> What makes you think s10b is only used by wcn6855?
>

I didn't say that. It's used by many components but they seem to be
all described in DT. But I get it, the schematics show it in so many
places, it would be risky to not keep it on.

> You clearly did not check the schematics so make sure you verify the
> rest as well before resending.
>
> And if any of these are valid, I think this should be part of the
> previous patch.
>

At least vreg_s11b and vreg_s12b should be fine. I'm not sure when
I'll respin the series though, we need to first figure out whether to
upstream the calibration variant property and what its name should be.

Bart

Re: [PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Dmitry Baryshkov]

On Thu, Sep 05, 2024 at 08:23:39PM GMT, Bartosz Golaszewski wrote:
> On Thu, Sep 5, 2024 at 4:04 PM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Thu, Sep 05, 2024 at 02:20:22PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > Remove the regulator-always-on property from the ones that used to be
> > > implicitly needed by the on-board WCN6855 now that its PMU is modeled in
> > > device-tree.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
> > >  1 file changed, 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > > index 88b31550f9df..1a9dac16c952 100644
> > > --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > > +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> > > @@ -479,7 +479,6 @@ vreg_s10b: smps10 {
> > >                       regulator-min-microvolt = <1800000>;
> > >                       regulator-max-microvolt = <1800000>;
> > >                       regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> > > -                     regulator-always-on;
> > >               };
> >
> > What makes you think s10b is only used by wcn6855?
> >
> 
> I didn't say that. It's used by many components but they seem to be
> all described in DT. But I get it, the schematics show it in so many
> places, it would be risky to not keep it on.

Well, that depends on the consumers. If all consumers are good and
voting, then it should be safe.

> > You clearly did not check the schematics so make sure you verify the
> > rest as well before resending.
> >
> > And if any of these are valid, I think this should be part of the
> > previous patch.
> >
> 
> At least vreg_s11b and vreg_s12b should be fine. I'm not sure when
> I'll respin the series though, we need to first figure out whether to
> upstream the calibration variant property and what its name should be.

-- 
With best wishes
Dmitry

Re: [PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Johan Hovold]

On Thu, Sep 05, 2024 at 10:27:24PM +0300, Dmitry Baryshkov wrote:
> On Thu, Sep 05, 2024 at 08:23:39PM GMT, Bartosz Golaszewski wrote:
> > On Thu, Sep 5, 2024 at 4:04 PM Johan Hovold <johan@kernel.org> wrote:
> > > On Thu, Sep 05, 2024 at 02:20:22PM +0200, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > >
> > > > Remove the regulator-always-on property from the ones that used to be
> > > > implicitly needed by the on-board WCN6855 now that its PMU is modeled in
> > > > device-tree.

> > > What makes you think s10b is only used by wcn6855?
> > 
> > I didn't say that. It's used by many components but they seem to be
> > all described in DT. But I get it, the schematics show it in so many
> > places, it would be risky to not keep it on.
> 
> Well, that depends on the consumers. If all consumers are good and
> voting, then it should be safe.

Right. But in this case, not all consumers are described in DT (e.g.
ddr) and this is effectively an always-on rail.

Johan

Re: [PATCH v3 4/4] arm64: dts: qcom: sc8280xp-x13s: keep less regulators always-on

[Dmitry Baryshkov]

On Fri, Sep 06, 2024 at 04:49:31PM GMT, Johan Hovold wrote:
> On Thu, Sep 05, 2024 at 10:27:24PM +0300, Dmitry Baryshkov wrote:
> > On Thu, Sep 05, 2024 at 08:23:39PM GMT, Bartosz Golaszewski wrote:
> > > On Thu, Sep 5, 2024 at 4:04 PM Johan Hovold <johan@kernel.org> wrote:
> > > > On Thu, Sep 05, 2024 at 02:20:22PM +0200, Bartosz Golaszewski wrote:
> > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > > >
> > > > > Remove the regulator-always-on property from the ones that used to be
> > > > > implicitly needed by the on-board WCN6855 now that its PMU is modeled in
> > > > > device-tree.
> 
> > > > What makes you think s10b is only used by wcn6855?
> > > 
> > > I didn't say that. It's used by many components but they seem to be
> > > all described in DT. But I get it, the schematics show it in so many
> > > places, it would be risky to not keep it on.
> > 
> > Well, that depends on the consumers. If all consumers are good and
> > voting, then it should be safe.
> 
> Right. But in this case, not all consumers are described in DT (e.g.
> ddr) and this is effectively an always-on rail.

Ack.

-- 
With best wishes
Dmitry