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 | 110 ++++++++++++++++++++++
 1 file changed, 110 insertions(+)

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

index 6020582b0a59..28721570c59f 100644
@@ -177,6 +177,17 @@ vreg_misc_3p3: regulator-misc-3p3 {
 		regulator-always-on;
 	};
 

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

+
 	vreg_wlan: regulator-wlan {
 		compatible = "regulator-fixed";
 
+&pcie4_port0 {
+	wifi@0 {
+		compatible = "pci17cb,1103";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;

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

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

Review

Quoted 3 lines

(quoted diff) +2 -0

+
+             qcom,ath11k-calibration-variant = "QC_8280XP_CRD";

Not "SC8280XP"?

From: Bartosz Golaszewski <[email protected]>

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

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

+&uart2 {

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

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

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.

With this we can drop the regulator-always-on properties from vreg_s11b and vreg_s12b as they will now be enabled by the power sequencing driver.

Tested-by Steev Klimaszewski <[email protected]> # Thinkpad X13s

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

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

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

index 6a28cab97189..7230d5420199 100644
@@ -400,6 +400,67 @@ usb1_sbu_mux: endpoint {
 			};
 		};
 	};
+
+	wcn6855-pmu {
+		compatible = "qcom,wcn6855-pmu";
+
+		pinctrl-0 = <&bt_default>, <&wlan_en>;
+		pinctrl-names = "default";
+
+		wlan-enable-gpios = <&tlmm 134 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
 

@@ -1258,20 +1327,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>;

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

-
-		pinctrl-0 = <&bt_default>;
-		pinctrl-names = "default";
 	};
 };
 

Quoted 11 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.

With this we can drop the regulator-always-on properties from vreg_s11b and vreg_s12b as they will now be enabled by the power sequencing driver.

Tested-by Steev Klimaszewski <[email protected]> # Thinkpad X13s

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

Without this patch I'm seeing an indefinite probe deferral with 6.12-rc1:

platform 1c00000.pcie:pcie@0:wifi@0: deferred probe pending: pci-pwrctl-pwrseq: Failed to get the power sequencer

Can you please look into that and make sure that the existing DT continues to work without such warnings.

arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts &uart2 { · line 1271

Quoted 3 lines

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

-
-             enable-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
-             swctrl-gpios = <&tlmm 132 GPIO_ACTIVE_HIGH>;

What about swctrl? You're just removing this pin from DT now without any comment on why you think that is the right thing to do.

Should this one also be an input to the PMU block?

Quoted 9 lines · Johan Hovold

Without this patch I'm seeing an indefinite probe deferral with 6.12-rc1:

platform 1c00000.pcie:pcie@0:wifi@0: deferred probe pending: pci-pwrctl-pwrseq: Failed to get the power sequencer

Can you please look into that and make sure that the existing DT continues to work without such warnings.

Ah, dammit, I missed the fact that X13s already has this node defined so PCI pwrctl will consume it and try to get the power sequencer handle. I'm wondering how to tackle it though... It will most likely require some kind of a driver quirk where we check if we have the PMU node and if not, then don't try to set up power sequencing. Any other ideas?

Quoted 11 lines · Bartosz Golaszewski

Quoted 9 lines · Johan Hovold

Without this patch I'm seeing an indefinite probe deferral with 6.12-rc1:

platform 1c00000.pcie:pcie@0:wifi@0: deferred probe pending: pci-pwrctl-pwrseq: Failed to get the power sequencer

Can you please look into that and make sure that the existing DT continues to work without such warnings.

Quoted 7 lines

Ah, dammit, I missed the fact that X13s already has this node defined so PCI pwrctl will consume it and try to get the power sequencer handle. I'm wondering how to tackle it though... It will most likely require some kind of a driver quirk where we check if we have the PMU node and if not, then don't try to set up power sequencing. Any other ideas?

This is untested but would it make sense?

drivers/pci/pwrctl/pci-pwrctl-pwrseq.c +26 -1

index a23a4312574b..071ee77c763d 100644
@@ -3,6 +3,7 @@
  * Copyright (C) 2024 Linaro Ltd.
  */
 
+#include <linux/cleanup.h>
 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>

@@ -87,7 +88,31 @@ static struct platform_driver pci_pwrctl_pwrseq_driver = {
 	},
 	.probe = pci_pwrctl_pwrseq_probe,
 };
-module_platform_driver(pci_pwrctl_pwrseq_driver);
+
+static int __init pci_pwrctl_pwrseq_init(void)
+{
+	/*
+	 * Old device trees for the Lenovo X13s have the "pci17cb,1103" node
+	 * defined but don't use power sequencing yet. If we register this
+	 * driver, it will match against this node and lead to emitting of
+	 * a warning in the kernel log when we cannot get the power sequencing
+	 * handle. Let's skip registering the platform driver if we're on X13s
+	 * but don't have the PMU node.
+	 */
+	if (of_machine_is_compatible("lenovo,thinkpad-x13s")) {
+		struct device_node *dn __free(device_node) =
+			of_find_compatible_node(NULL, NULL, "qcom,wcn6855-pmu");
+		if (!dn)
+			return 0;
+	}
+
+	return platform_driver_register(&pci_pwrctl_pwrseq_driver);
+}
+
+static void __exit pci_pwrctl_pwrseq_exit(void)
+{
+	platform_driver_unregister(&pci_pwrctl_pwrseq_driver);
+}
 
 MODULE_AUTHOR("Bartosz Golaszewski <[email protected]>");
 MODULE_DESCRIPTION("Generic PCI Power Control module for power

sequenced devices");

X13s is the only platform that would use one of the compatibles supported by this driver before power sequencing so it should be a one-off quirk.

Quoted 70 lines · Bartosz Golaszewski

Quoted 11 lines · Bartosz Golaszewski

Quoted 9 lines · Johan Hovold

Without this patch I'm seeing an indefinite probe deferral with 6.12-rc1:

platform 1c00000.pcie:pcie@0:wifi@0: deferred probe pending: pci-pwrctl-pwrseq: Failed to get the power sequencer

Can you please look into that and make sure that the existing DT continues to work without such warnings.

Quoted 7 lines

Ah, dammit, I missed the fact that X13s already has this node defined so PCI pwrctl will consume it and try to get the power sequencer handle. I'm wondering how to tackle it though... It will most likely require some kind of a driver quirk where we check if we have the PMU node and if not, then don't try to set up power sequencing. Any other ideas?

This is untested but would it make sense?

drivers/pci/pwrctl/pci-pwrctl-pwrseq.c +26 -1

index a23a4312574b..071ee77c763d 100644
@@ -3,6 +3,7 @@
  * Copyright (C) 2024 Linaro Ltd.
  */
 
+#include <linux/cleanup.h>
 #include <linux/device.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>

@@ -87,7 +88,31 @@ static struct platform_driver pci_pwrctl_pwrseq_driver = {
      },
      .probe = pci_pwrctl_pwrseq_probe,
 };
-module_platform_driver(pci_pwrctl_pwrseq_driver);
+
+static int __init pci_pwrctl_pwrseq_init(void)
+{
+     /*
+      * Old device trees for the Lenovo X13s have the "pci17cb,1103" node
+      * defined but don't use power sequencing yet. If we register this
+      * driver, it will match against this node and lead to emitting of
+      * a warning in the kernel log when we cannot get the power sequencing
+      * handle. Let's skip registering the platform driver if we're on X13s
+      * but don't have the PMU node.
+      */
+     if (of_machine_is_compatible("lenovo,thinkpad-x13s")) {
+             struct device_node *dn __free(device_node) =
+                     of_find_compatible_node(NULL, NULL, "qcom,wcn6855-pmu");
+             if (!dn)
+                     return 0;
+     }
+
+     return platform_driver_register(&pci_pwrctl_pwrseq_driver);
+}
+
+static void __exit pci_pwrctl_pwrseq_exit(void)
+{
+     platform_driver_unregister(&pci_pwrctl_pwrseq_driver);
+}
 
 MODULE_AUTHOR("Bartosz Golaszewski <[email protected]>");
 MODULE_DESCRIPTION("Generic PCI Power Control module for power

sequenced devices");

Quoted 3 lines

X13s is the only platform that would use one of the compatibles supported by this driver before power sequencing so it should be a one-off quirk.

I'm guessing the pci17cb,1107 node in x1e80100-lenovo-yoga-slim7x is also affected?

Maybe you can check if the node has one of the -supply properties and return -ENODEV from pci_pwrctl_pwrseq_probe() otherwise?