arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

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

---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 128 insertions(+), 11 deletions(-)

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

index cd0db4f31d4a..c9b1600c57ef 100644

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +7 -0

+		compatible = "qcom,qca6390-pmu";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+		vddaon-supply = <&vreg_s6a_0p95>;
+		vddpmu-supply = <&vreg_s2f_0p95>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+			};

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+		vddaon-supply = <&vreg_pmu_aon_0p59>;

Quoted 2 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Quoted 4 lines

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

With linux-arm-msm and deviectree in there, you have a fairly big limited audience... I think if anything, your proposal is doomed by the lack of a proper commit message describing what this is.

Below you'll find some questions/feedback based on our previous discussions on the topic, although I'm not able to understand the motivations behind what you propose - or even fully what it is that you're proposing.

Quoted 6 lines

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

Why do you need to make up this intermediate/fake "PMU" thing? The regulators are reference counted already.

Quoted 3 lines

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

I was under the impression that the supplies in the bluetooth binding are the supply pads of the chip. Where the power to those pads come from is not a property of the binding.

So what you need to do is describe why the pads suddenly changed.

Quoted 14 lines

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

---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 128 insertions(+), 11 deletions(-)

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

index cd0db4f31d4a..c9b1600c57ef 100644
@@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
              regulator-always-on;
      };
 

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 111

Quoted 1 line

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+     qca6390_pmu: pmu@0 {

This is not a thing.

Quoted 13 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +13 -0

+             compatible = "qcom,qca6390-pmu";
+
+             pinctrl-names = "default";
+             pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+             vddaon-supply = <&vreg_s6a_0p95>;
+             vddpmu-supply = <&vreg_s2f_0p95>;
+             vddrfa1-supply = <&vreg_s2f_0p95>;
+             vddrfa2-supply = <&vreg_s8c_1p3>;
+             vddrfa3-supply = <&vreg_s5a_1p9>;
+             vddpcie1-supply = <&vreg_s8c_1p3>;
+             vddpcie2-supply = <&vreg_s5a_1p9>;
+             vddio-supply = <&vreg_s4a_1p8>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 128

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+
+             bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+             wifi-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+             swctrl-gpios = <&tlmm 124 GPIO_ACTIVE_HIGH>;

Are these collected here because we still have convinced ourselves that they need to be handled from a common place, or did you actually find some documentation you can point to that shows this is necessary?

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 134

Quoted 6 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +6 -0

+
+             regulators {
+                     vreg_pmu_rfa_cmn: ldo0 {
+                             regulator-name = "vreg_pmu_rfa_cmn";
+                             regulator-min-microvolt = <760000>;
+                             regulator-max-microvolt = <840000>;

These limits should be applied to &vreg_s2f_0p95 (although I'm just guessing how this maps to the upstream supply...

Quoted 2 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+                     };

[..]

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

@@ -734,6 +816,24 @@ &pcie0_phy {
      vdda-pll-supply = <&vreg_l9a_1p2>;
 };
 

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 821

Quoted 3 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +3 -0

+&pcieport0 {
+     wifi@0 {
+             compatible = "pci17cb,1101";

Does this compatible somehow bind to a entity that knows what to do with the regulators below?

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+             reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+             vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+             vddaon-supply = <&vreg_pmu_aon_0p59>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 835

Quoted 10 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +10 -0

+             vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+             vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+             vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+             vddrfa0-supply = <&vreg_pmu_rfa_0p8>;
+             vddrfa1-supply = <&vreg_pmu_rfa_1p2>;
+             vddrfa2-supply = <&vreg_pmu_rfa_1p7>;
+             vddpcie0-supply = <&vreg_pmu_pcie_0p9>;
+             vddpcie1-supply = <&vreg_pmu_pcie_1p8>;
+     };
+};

Regards,
Bjorn

Quoted 4 lines · Bjorn Andersson

Quoted 2 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Quoted 9 lines

Quoted 4 lines

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

With linux-arm-msm and deviectree in there, you have a fairly big limited audience... I think if anything, your proposal is doomed by the lack of a proper commit message describing what this is.

By limiting I meant compared to the PCI power sequencing series but you're right, I should have linked that series in here. In any case - this is not intended for upstream, I literally wanted input on whether this representation is correct before I send a PoC of the pwrseq subsystem using it.

Quoted 12 lines

Below you'll find some questions/feedback based on our previous discussions on the topic, although I'm not able to understand the motivations behind what you propose - or even fully what it is that you're proposing.

Quoted 6 lines

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

Quoted 3 lines

Why do you need to make up this intermediate/fake "PMU" thing? The regulators are reference counted already.

Dmitry insists that for QCA6490 we *do* need to implement a proper power sequencing with delays between enabling WLAN and BT GPIOs.

See: https://lore.kernel.org/netdev/CAA8EJpqyK=pkjEofWV595tp29vjkCeWKYr-KOJh_hBiBbkVBew@mail.gmail.com/

Even though the regulators are reference counted, this is not enough. Dmitry tried to implement a power sequencing framework some time ago but the main complaint was that explicit properties like bt-pwrseq are not a right fit for DT as they don't represent hardware. We still need to centralize the control over the shared resources though but what I want to propose is doing that with a more realistic representation of HW and just reusing phandle connections between DT nodes to retrieve the correct pwrseq struct in the driver. But this is implementation detail and before I want to clear the HW representation with DT maintainers.

Dmitry is also correct in pointing out that It's also simply an incorrect representation of what is on the board as the PMU is a discrete module, has its inputs and outputs, even though they're inside the package.

Quoted 4 lines

Quoted 3 lines

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

Quoted 4 lines

I was under the impression that the supplies in the bluetooth binding are the supply pads of the chip. Where the power to those pads come from is not a property of the binding.

We already model the WLAN and BT modules as separate elements even though they're in the same package. For consistency we should model the PMU module too.

And for the record: I would love to stick to what we have now as it would make my PCI power sequencing series much easier to get upstream but it will result in problems later on, I have to give it to Dmitry.

Quoted 16 lines

So what you need to do is describe why the pads suddenly changed.

Quoted 14 lines

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

---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 128 insertions(+), 11 deletions(-)

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

index cd0db4f31d4a..c9b1600c57ef 100644
@@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
              regulator-always-on;
      };
 

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 111

Quoted 1 line

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+     qca6390_pmu: pmu@0 {

This is not a thing.

What isn't?

Quoted 13 lines

Quoted 13 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +13 -0

+             compatible = "qcom,qca6390-pmu";
+
+             pinctrl-names = "default";
+             pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+             vddaon-supply = <&vreg_s6a_0p95>;
+             vddpmu-supply = <&vreg_s2f_0p95>;
+             vddrfa1-supply = <&vreg_s2f_0p95>;
+             vddrfa2-supply = <&vreg_s8c_1p3>;
+             vddrfa3-supply = <&vreg_s5a_1p9>;
+             vddpcie1-supply = <&vreg_s8c_1p3>;
+             vddpcie2-supply = <&vreg_s5a_1p9>;
+             vddio-supply = <&vreg_s4a_1p8>;

Quoted 9 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 128

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+
+             bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+             wifi-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+             swctrl-gpios = <&tlmm 124 GPIO_ACTIVE_HIGH>;

Are these collected here because we still have convinced ourselves that they need to be handled from a common place, or did you actually find some documentation you can point to that shows this is necessary?

So the datasheet is not clear on that but it says: "bluetooth enable signal from host" and since the regulators above are also "from host" I figured the best fit is here.

Quoted 7 lines

Quoted 6 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +6 -0

+
+             regulators {
+                     vreg_pmu_rfa_cmn: ldo0 {
+                             regulator-name = "vreg_pmu_rfa_cmn";
+                             regulator-min-microvolt = <760000>;
+                             regulator-max-microvolt = <840000>;

Quoted 2 lines

These limits should be applied to &vreg_s2f_0p95 (although I'm just guessing how this maps to the upstream supply...

I'm not following. Why?

Quoted 7 lines

Quoted 2 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+                     };

[..]

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

@@ -734,6 +816,24 @@ &pcie0_phy {
      vdda-pll-supply = <&vreg_l9a_1p2>;
 };
 

Quoted 7 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 821

Quoted 3 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +3 -0

+&pcieport0 {
+     wifi@0 {
+             compatible = "pci17cb,1101";

Does this compatible somehow bind to a entity that knows what to do with the regulators below?

Ok, so what does that matter? This is device-tree. What linux does behind the scenes is irrelevant - what is important is that there is an ATH11K module here as represented by this PCI vendor/model codes and that it's supplied by these regulators.

Bart

Quoted 17 lines

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+             reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+             vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+             vddaon-supply = <&vreg_pmu_aon_0p59>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 835

Quoted 10 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +10 -0

+             vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+             vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+             vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+             vddrfa0-supply = <&vreg_pmu_rfa_0p8>;
+             vddrfa1-supply = <&vreg_pmu_rfa_1p2>;
+             vddrfa2-supply = <&vreg_pmu_rfa_1p7>;
+             vddpcie0-supply = <&vreg_pmu_pcie_0p9>;
+             vddpcie1-supply = <&vreg_pmu_pcie_1p8>;
+     };
+};

Regards,
Bjorn

Quoted 33 lines · Bartosz Golaszewski

Quoted 4 lines · Bjorn Andersson

Quoted 2 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Quoted 9 lines

Quoted 4 lines

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

With linux-arm-msm and deviectree in there, you have a fairly big limited audience... I think if anything, your proposal is doomed by the lack of a proper commit message describing what this is.

By limiting I meant compared to the PCI power sequencing series but you're right, I should have linked that series in here. In any case - this is not intended for upstream, I literally wanted input on whether this representation is correct before I send a PoC of the pwrseq subsystem using it.

Quoted 12 lines

Below you'll find some questions/feedback based on our previous discussions on the topic, although I'm not able to understand the motivations behind what you propose - or even fully what it is that you're proposing.

Quoted 6 lines

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

Quoted 9 lines

Quoted 3 lines

Why do you need to make up this intermediate/fake "PMU" thing? The regulators are reference counted already.

Dmitry insists that for QCA6490 we *do* need to implement a proper power sequencing with delays between enabling WLAN and BT GPIOs.

See: https://lore.kernel.org/netdev/CAA8EJpqyK=pkjEofWV595tp29vjkCeWKYr-KOJh_hBiBbkVBew@mail.gmail.com/

I had not seen that comment before, would have been excellent to include in your "problem description".

Quoted 11 lines

Even though the regulators are reference counted, this is not enough. Dmitry tried to implement a power sequencing framework some time ago but the main complaint was that explicit properties like bt-pwrseq are not a right fit for DT as they don't represent hardware. We still need to centralize the control over the shared resources though but what I want to propose is doing that with a more realistic representation of HW and just reusing phandle connections between DT nodes to retrieve the correct pwrseq struct in the driver. But this is implementation detail and before I want to clear the HW representation with DT maintainers.

In my view Dmitry had at least one proposal, that was rejected, where he represented the qca6390 package as a thing in DeviceTree.

Quoted 5 lines

Dmitry is also correct in pointing out that It's also simply an incorrect representation of what is on the board as the PMU is a discrete module, has its inputs and outputs, even though they're inside the package.

I'm not sure what you're trying to say here. There's no "PMU module" on the board, it's a block within the QCA6390. But perhaps that's what you're also saying?

Quoted 33 lines · Bartosz Golaszewski

Quoted 4 lines · Bjorn Andersson

Quoted 2 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Quoted 9 lines

Quoted 4 lines

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

With linux-arm-msm and deviectree in there, you have a fairly big limited audience... I think if anything, your proposal is doomed by the lack of a proper commit message describing what this is.

By limiting I meant compared to the PCI power sequencing series but you're right, I should have linked that series in here. In any case - this is not intended for upstream, I literally wanted input on whether this representation is correct before I send a PoC of the pwrseq subsystem using it.

Quoted 12 lines

Below you'll find some questions/feedback based on our previous discussions on the topic, although I'm not able to understand the motivations behind what you propose - or even fully what it is that you're proposing.

Quoted 6 lines

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

Quoted 9 lines

Quoted 3 lines

Why do you need to make up this intermediate/fake "PMU" thing? The regulators are reference counted already.

Dmitry insists that for QCA6490 we *do* need to implement a proper power sequencing with delays between enabling WLAN and BT GPIOs.

See: https://lore.kernel.org/netdev/CAA8EJpqyK=pkjEofWV595tp29vjkCeWKYr-KOJh_hBiBbkVBew@mail.gmail.com/

I had not seen that comment before, would have been excellent to include in your "problem description".

Quoted 11 lines

Even though the regulators are reference counted, this is not enough. Dmitry tried to implement a power sequencing framework some time ago but the main complaint was that explicit properties like bt-pwrseq are not a right fit for DT as they don't represent hardware. We still need to centralize the control over the shared resources though but what I want to propose is doing that with a more realistic representation of HW and just reusing phandle connections between DT nodes to retrieve the correct pwrseq struct in the driver. But this is implementation detail and before I want to clear the HW representation with DT maintainers.

In my view Dmitry had at least one proposal, that was rejected, where he represented the qca6390 package as a thing in DeviceTree.

Quoted 5 lines

Dmitry is also correct in pointing out that It's also simply an incorrect representation of what is on the board as the PMU is a discrete module, has its inputs and outputs, even though they're inside the package.

I'm not sure what you're trying to say here. There's no "PMU module" on the board, it's a block within the QCA6390. But perhaps that's what you're also saying?

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

Quoted 9 lines

Quoted 4 lines

I was under the impression that the supplies in the bluetooth binding are the supply pads of the chip. Where the power to those pads come from is not a property of the binding.

We already model the WLAN and BT modules as separate elements even though they're in the same package. For consistency we should model the PMU module too.

So what you're proposing is that the PMU is the consumer of the external supplies, and it in turn provides a set of internal power-rails which should be consumed by the WiFi and BT modules.

That's sounds like a plausible way to get around the problem that we don't want to represent a fake device in DeviceTree.

That still doesn't answer me why bluetooth suddenly now has an input named "vddpcie0", can you please point me to the documentation of the internal power routing in the QCA6390 that confirms this?

Quoted 20 lines

And for the record: I would love to stick to what we have now as it would make my PCI power sequencing series much easier to get upstream but it will result in problems later on, I have to give it to Dmitry.

Quoted 16 lines

So what you need to do is describe why the pads suddenly changed.

Quoted 14 lines

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

---
  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
  arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
  2 files changed, 128 insertions(+), 11 deletions(-)

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

index cd0db4f31d4a..c9b1600c57ef 100644
@@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
               regulator-always-on;
       };
 

Quoted 7 lines

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 111

Quoted 1 line

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+     qca6390_pmu: pmu@0 {

This is not a thing.

What isn't?

My bad. You're right, there is a block in the corner of the QCA6390 called "PMU".

Quoted 23 lines

Quoted 13 lines

Quoted 13 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +13 -0

+             compatible = "qcom,qca6390-pmu";
+
+             pinctrl-names = "default";
+             pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+             vddaon-supply = <&vreg_s6a_0p95>;
+             vddpmu-supply = <&vreg_s2f_0p95>;
+             vddrfa1-supply = <&vreg_s2f_0p95>;
+             vddrfa2-supply = <&vreg_s8c_1p3>;
+             vddrfa3-supply = <&vreg_s5a_1p9>;
+             vddpcie1-supply = <&vreg_s8c_1p3>;
+             vddpcie2-supply = <&vreg_s5a_1p9>;
+             vddio-supply = <&vreg_s4a_1p8>;

Quoted 9 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts lt9611_3v3: lt9611-3v3 { · line 128

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+
+             bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+             wifi-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+             swctrl-gpios = <&tlmm 124 GPIO_ACTIVE_HIGH>;

Are these collected here because we still have convinced ourselves that they need to be handled from a common place, or did you actually find some documentation you can point to that shows this is necessary?

Quoted 4 lines

So the datasheet is not clear on that but it says: "bluetooth enable signal from host" and since the regulators above are also "from host" I figured the best fit is here.

Per Dmitry's argument that you linked above, bt-enable and wifi-enable should be the only things that you need to synchronize.

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +6 -0

+
+             regulators {
+                     vreg_pmu_rfa_cmn: ldo0 {
+                             regulator-name = "vreg_pmu_rfa_cmn";
+                             regulator-min-microvolt = <760000>;
+                             regulator-max-microvolt = <840000>;

Quoted 5 lines

Quoted 2 lines

These limits should be applied to &vreg_s2f_0p95 (although I'm just guessing how this maps to the upstream supply...

I'm not following. Why?

Are you saying that the PMU contains a set of LDOs or similar that alter the voltage from what's provided on the external pads?

Quoted 16 lines

Quoted 8 lines

Quoted 3 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +1 -0

+                     };

[..]

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +0 -0

@@ -734,6 +816,24 @@ &pcie0_phy {
       vdda-pll-supply = <&vreg_l9a_1p2>;
  };
 

Quoted 7 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 821

Quoted 3 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +3 -0

+&pcieport0 {
+     wifi@0 {
+             compatible = "pci17cb,1101";

Does this compatible somehow bind to a entity that knows what to do with the regulators below?

Quoted 5 lines

Ok, so what does that matter? This is device-tree. What linux does behind the scenes is irrelevant - what is important is that there is an ATH11K module here as represented by this PCI vendor/model codes and that it's supplied by these regulators.

I'm just making guesses about the design and how this fits into previous discussions on the subject of PCI power sequencing, because you didn't tell me what any of the things in this patch are.

Regards,
Bjorn

Quoted 19 lines

Bart

Quoted 17 lines

Quoted 4 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +4 -0

+             reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+             vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+             vddaon-supply = <&vreg_pmu_aon_0p59>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 835

Quoted 10 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +10 -0

+             vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+             vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+             vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+             vddrfa0-supply = <&vreg_pmu_rfa_0p8>;
+             vddrfa1-supply = <&vreg_pmu_rfa_1p2>;
+             vddrfa2-supply = <&vreg_pmu_rfa_1p7>;
+             vddpcie0-supply = <&vreg_pmu_pcie_0p9>;
+             vddpcie1-supply = <&vreg_pmu_pcie_1p8>;
+     };
+};

Regards,
Bjorn

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +6 -0

+
+             regulators {
+                     vreg_pmu_rfa_cmn: ldo0 {
+                             regulator-name = "vreg_pmu_rfa_cmn";
+                             regulator-min-microvolt = <760000>;
+                             regulator-max-microvolt = <840000>;

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

These limits should be applied to &vreg_s2f_0p95 (although I'm just guessing how this maps to the upstream supply...

I'm not following. Why?

Are you saying that the PMU contains a set of LDOs or similar that alter the voltage from what's provided on the external pads?

It's what I observe on WCN785x, on one side we have the usual VDD_AON/VDD_PMU/VDD_RFA/... and on the other side the WCN internal PMU generates the VDDXX_PMU_XXX voltages that are consumed by the WCN785x again.
The schematics is clearly split into different entities of the WCN785x:
- PMU
- VSS
- GND
- PWR
- CONFIG
- GPIO
- RFA
- PCIE

Neil

Quoted 6 lines

Ok, so what does that matter? This is device-tree. What linux does behind the scenes is irrelevant - what is important is that there is an ATH11K module here as represented by this PCI vendor/model codes and that it's supplied by these regulators.

I'm just making guesses about the design and how this fits into previous discussions on the subject of PCI power sequencing, because you didn't tell me what any of the things in this patch are.

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

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

---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 128 insertions(+), 11 deletions(-)

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +87 -0

index cd0db4f31d4a..c9b1600c57ef 100644
@@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
                regulator-always-on;
        };
 
+       qca6390_pmu: pmu@0 {
+               compatible = "qcom,qca6390-pmu";
+
+               pinctrl-names = "default";
+               pinctrl-0 = <&bt_en_state>, <&wlan_en_state>;
+
+               vddaon-supply = <&vreg_s6a_0p95>;
+               vddpmu-supply = <&vreg_s2f_0p95>;
+               vddrfa1-supply = <&vreg_s2f_0p95>;
+               vddrfa2-supply = <&vreg_s8c_1p3>;
+               vddrfa3-supply = <&vreg_s5a_1p9>;
+               vddpcie1-supply = <&vreg_s8c_1p3>;
+               vddpcie2-supply = <&vreg_s5a_1p9>;
+               vddio-supply = <&vreg_s4a_1p8>;
+
+               bt-enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
+               wifi-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+               swctrl-gpios = <&tlmm 124 GPIO_ACTIVE_HIGH>;
+
+               regulators {
+                       vreg_pmu_rfa_cmn: ldo0 {
+                               regulator-name = "vreg_pmu_rfa_cmn";
+                               regulator-min-microvolt = <760000>;
+                               regulator-max-microvolt = <840000>;
+                       };
+
+                       vreg_pmu_aon_0p59: ldo1 {
+                               regulator-name = "vreg_pmu_aon_0p59";
+                               regulator-min-microvolt = <540000>;
+                               regulator-max-microvolt = <840000>;
+                       };
+
+                       vreg_pmu_wlcx_0p8: ldo2 {
+                               regulator_name = "vreg_pmu_wlcx_0p8";
+                               regulator-min-microvolt = <760000>;
+                               regulator-max-microvolt = <840000>;
+                       };
+
+                       vreg_pmu_wlmx_0p85: ldo3 {
+                               regulator-name = "vreg_pmu_wlmx_0p85";
+                               regulator-min-microvolt = <810000>;
+                               regulator-max-microvolt = <890000>;
+                       };
+
+                       vreg_pmu_btcmx_0p85: ldo4 {
+                               regulator-name = "vreg_pmu_btcmx_0p85";
+                               regulator-min-microvolt = <810000>;
+                               regulator-max-microvolt = <890000>;
+                       };
+
+                       vreg_pmu_rfa_0p8: ldo5 {
+                               regulator-name = "vreg_pmu_rfa_0p8";
+                               regulator-min-microvolt = <760000>;
+                               regulator-max-microvolt = <840000>;
+                       };
+
+                       vreg_pmu_rfa_1p2: ldo6 {
+                               regulator-name = "vreg_pmu_rfa_1p2";
+                               regulator-min-microvolt = <1187000>;
+                               regulator-max-microvolt = <1313000>;
+                       };
+
+                       vreg_pmu_rfa_1p7: ldo7 {
+                               regulator_name = "vreg_pmu_rfa_1p7";
+                               regulator-min-microvolt = <1710000>;
+                               regulator-max-microvolt = <1890000>;
+                       };
+
+                       vreg_pmu_pcie_0p9: ldo8 {
+                               regulator_name = "vreg_pmu_pcie_0p9";
+                               regulator-min-microvolt = <870000>;
+                               regulator-max-microvolt = <970000>;
+                       };
+
+                       vreg_pmu_pcie_1p8: ldo9 {
+                               regulator_name = "vreg_pmu_pcie_1p8";
+                               regulator-min-microvolt = <1710000>;
+                               regulator-max-microvolt = <1890000>;
+                       };
+               };
+       };
+
        thermal-zones {
                conn-thermal {
                        polling-delay-passive = <0>;

@@ -734,6 +816,24 @@ &pcie0_phy {
        vdda-pll-supply = <&vreg_l9a_1p2>;
 };
 
+&pcieport0 {
+       wifi@0 {
+               compatible = "pci17cb,1101";
+               reg = <0x10000 0x0 0x0 0x0 0x0>;
+

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +3 -0

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

Quoted 16 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

Quoted 1 line

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

My main concern is whether this is going to pass the regulator subsystem locking. Basically you have a driver for regulators, which will itself call into the regulator subsytem. It might be reentrant. Or it might not.

Quoted 18 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +11 -0

+
        thermal-zones {
                conn-thermal {
                        polling-delay-passive = <0>;

@@ -734,6 +816,24 @@ &pcie0_phy {
        vdda-pll-supply = <&vreg_l9a_1p2>;
 };
 
+&pcieport0 {
+       wifi@0 {
+               compatible = "pci17cb,1101";
+               reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+               vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+               vddaon-supply = <&vreg_pmu_aon_0p59>;
+               vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+               vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+               vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 833

Quoted 5 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +5 -0

+               vddrfa0-supply = <&vreg_pmu_rfa_0p8>;
+               vddrfa1-supply = <&vreg_pmu_rfa_1p2>;
+               vddrfa2-supply = <&vreg_pmu_rfa_1p7>;
+               vddpcie0-supply = <&vreg_pmu_pcie_0p9>;
+               vddpcie1-supply = <&vreg_pmu_pcie_1p8>;

This really feels like an overkill, All those voltages are handled by the PMU itself, rather than being requested by the WiFi or BT drivers.

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts &pcie0_phy { · line 839

Quoted 6 lines

arch/arm64/boot/dts/qcom/qrb5165-rb5.dts +3 -0

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

--
With best wishes
Dmitry

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

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

Quoted 15 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

Quoted 1 line

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

Please provide lore link to the binding.

Best regards,
Krzysztof

Quoted 19 lines · Krzysztof Kozlowski

Quoted 16 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

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

Quoted 5 lines

Please provide lore link to the binding.

Best regards,
Krzysztof

This is the one:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml

Quoted 27 lines · Bartosz Golaszewski

Quoted 24 lines · Krzysztof Kozlowski

Quoted 12 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

I'm limiting the audience of this compared to the PCI power sequencing series as I wanted to run the DT part by the maintainers before I commit to a doomed effort.

Here is the DT representation of the QCA6390's PMU with its inputs and outputs. If I were to implement the pwrseq framework that would be able to assign the relevant pwrseq data to the consumer based on the actual regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would that fly with you?

Quoted 4 lines

We'd need to deprecate the existing BT bindings but unfortunately they are already described as consuming the host PMIC regulators in bindings.

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

Please provide lore link to the binding.

Best regards,
Krzysztof

Quoted 2 lines

This is the one:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml

This does not describe your PMU node. Maybe lack of the binding was intentional? In such case I missed it from commit msg...