arm64: dts: qcom: sc8280xp: enable WLAN and Bluetooth

From: Konrad Dybcio <[email protected]>

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 <[email protected]>

Signed-off-by Konrad Dybcio <[email protected]>

[Bartosz:
- write the commit message,
- rebase Konrad's commit,
- fix one of the supplies' name]

Co-developed-by Bartosz Golaszewski <[email protected]>

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++
 1 file changed, 108 insertions(+)

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +4 -0

@@ -583,6 +668,23 @@ &pcie4_phy {
 	status = "okay";
 };
 
+&pcie4_port0 {
+	wifi@0 {
+		compatible = "pci17cb,1103";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +3 -0

+	};
+};
+
 &pmc8280c_lpg {
 	status = "okay";
 };

Quoted 26 lines · Bartosz Golaszewski

From: Konrad Dybcio <[email protected]>

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 <[email protected]>

Signed-off-by Konrad Dybcio <[email protected]>

[Bartosz:
- write the commit message,
- rebase Konrad's commit,
- fix one of the supplies' name]

Co-developed-by Bartosz Golaszewski <[email protected]>

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++
 1 file changed, 108 insertions(+)

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +4 -0

@@ -583,6 +668,23 @@ &pcie4_phy {
      status = "okay";
 };
 
+&pcie4_port0 {
+     wifi@0 {
+             compatible = "pci17cb,1103";
+             reg = <0x10000 0x0 0x0 0x0 0x0>;

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts &pcie4_phy { · line 684

Quoted 10 lines

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +10 -0

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

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts &pcie4_phy { · line 690

Quoted 6 lines

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +3 -0

+     };
+};
+
 &pmc8280c_lpg {
      status = "okay";
 };

--
With best wishes
Dmitry

Quoted 41 lines · Dmitry Baryshkov

Quoted 26 lines · Bartosz Golaszewski

From: Konrad Dybcio <[email protected]>

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 <[email protected]>

Signed-off-by Konrad Dybcio <[email protected]>

[Bartosz:
- write the commit message,
- rebase Konrad's commit,
- fix one of the supplies' name]

Co-developed-by Bartosz Golaszewski <[email protected]>

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 108 ++++++++++++++++++++++
 1 file changed, 108 insertions(+)

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +4 -0

@@ -583,6 +668,23 @@ &pcie4_phy {
      status = "okay";
 };
 
+&pcie4_port0 {
+     wifi@0 {
+             compatible = "pci17cb,1103";
+             reg = <0x10000 0x0 0x0 0x0 0x0>;

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts &pcie4_phy { · line 684

Quoted 10 lines

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +10 -0

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

Quoted 2 lines

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

Quoted 10 lines

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts &pcie4_phy { · line 690

Quoted 6 lines

arch/arm64/boot/dts/qcom/sc8280xp-crd.dts +3 -0

+     };
+};
+
 &pmc8280c_lpg {
      status = "okay";
 };

--
With best wishes
Dmitry

Quoted 11 lines

Quoted 6 lines

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.

Quoted 12 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 6 lines

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?

Quoted 20 lines · Bartosz Golaszewski

Quoted 18 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 4 lines

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

Quoted 26 lines · Konrad Dybcio

Quoted 24 lines · Bartosz Golaszewski

Quoted 12 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 6 lines

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?

Quoted 2 lines

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.

Signature · 3 lines

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

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

Quoted 31 lines · Kalle Valo

Quoted 28 lines · Konrad Dybcio

Quoted 20 lines · Bartosz Golaszewski

Quoted 12 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 4 lines

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

Quoted 3 lines

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?

Quoted 37 lines · Dmitry Baryshkov

Quoted 34 lines · Kalle Valo

Quoted 21 lines · Konrad Dybcio

Quoted 20 lines · Bartosz Golaszewski

Quoted 18 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 3 lines

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.

Quoted 44 lines · Bartosz Golaszewski

Quoted 40 lines · Dmitry Baryshkov

Quoted 28 lines · Kalle Valo

Quoted 26 lines · Konrad Dybcio

Quoted 24 lines · Bartosz Golaszewski

Quoted 12 lines · Dmitry Baryshkov

Quoted 11 lines

Quoted 6 lines

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.

Quoted 6 lines

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?

Quoted 6 lines

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 14 lines · Dmitry Baryshkov

Quoted 11 lines · Bartosz Golaszewski

Quoted 4 lines · Dmitry Baryshkov

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.

Quoted 3 lines

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?

Quoted 3 lines · Kalle Valo

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?

Quoted 6 lines · Dmitry Baryshkov

Quoted 3 lines · Kalle Valo

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?

Quoted 2 lines

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.

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]> # Thinkpad X13s

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 98 ++++++++++++++++---
 1 file changed, 86 insertions(+), 12 deletions(-)

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +0 -0

index 6a28cab97189..88b31550f9df 100644

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +5 -0

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

Quoted 12 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]> # Thinkpad X13s

Signed-off-by Bartosz Golaszewski <[email protected]>

---
 .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts    | 98 ++++++++++++++++---
 1 file changed, 86 insertions(+), 12 deletions(-)

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts usb1_sbu_mux: endpoint { · line 407

Quoted 13 lines

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +5 -0

index 6a28cab97189..88b31550f9df 100644
@@ -400,6 +400,67 @@ usb1_sbu_mux: endpoint {
                        };
                };
        };
+
+       wcn6855-pmu {
+               compatible = "qcom,wcn6855-pmu";
+
+               pinctrl-0 = <&wlan_en>;

pinctrl for the bt-enable pin?

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
 1 file changed, 4 deletions(-)

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +0 -0

index 88b31550f9df..1a9dac16c952 100644

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
 1 file changed, 4 deletions(-)

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts vreg_s10b: smps10 { · line 482

Quoted 10 lines

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +0 -1

index 88b31550f9df..1a9dac16c952 100644
@@ -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.

Quoted 13 lines · Johan Hovold

Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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 <[email protected]>

---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ----
 1 file changed, 4 deletions(-)

Quoted 13 lines

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts vreg_s10b: smps10 { · line 482

Quoted 10 lines

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts +0 -1

index 88b31550f9df..1a9dac16c952 100644
@@ -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.

Quoted 6 lines

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.

Quoted 7 lines · Bartosz Golaszewski

Quoted 6 lines · Johan Hovold

Quoted 5 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 5 lines

Quoted 1 line

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.

Quoted 15 lines · Dmitry Baryshkov

Quoted 13 lines · Bartosz Golaszewski

Quoted 8 lines · Johan Hovold

Quoted 5 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

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.

Quoted 2 lines

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.