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

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

[Bartosz Golaszewski]

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

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 <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index cd0db4f31d4a..c9b1600c57ef 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -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>;
+
+		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>;
+		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>;
+	};
+};
+
 &pcie1 {
 	status = "okay";
 };
@@ -1303,6 +1403,14 @@ sdc2_card_det_n: sd-card-det-n-state {
 		function = "gpio";
 		bias-pull-up;
 	};
+
+	wlan_en_state: wlan-default-state {
+		pins = "gpio20";
+		function = "gpio";
+		drive-strength = <16>;
+		output-low;
+		bias-pull-up;
+	};
 };
 
 &uart6 {
@@ -1311,17 +1419,16 @@ &uart6 {
 	bluetooth {
 		compatible = "qcom,qca6390-bt";
 
-		pinctrl-names = "default";
-		pinctrl-0 = <&bt_en_state>;
-
-		enable-gpios = <&tlmm 21 GPIO_ACTIVE_HIGH>;
-
-		vddio-supply = <&vreg_s4a_1p8>;
-		vddpmu-supply = <&vreg_s2f_0p95>;
-		vddaon-supply = <&vreg_s6a_0p95>;
-		vddrfa0p9-supply = <&vreg_s2f_0p95>;
-		vddrfa1p3-supply = <&vreg_s8c_1p3>;
-		vddrfa1p9-supply = <&vreg_s5a_1p9>;
+		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>;
+		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>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 760501c1301a..fef9c314ce55 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2197,6 +2197,16 @@ pcie0: pcie@1c00000 {
 			dma-coherent;
 
 			status = "disabled";
+
+			pcieport0: pcie@0 {
+				device_type = "pci";
+				reg = <0x0 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				ranges;
+
+				bus-range = <0x01 0xff>;
+			};
 		};
 
 		pcie0_phy: phy@1c06000 {
-- 
2.40.1

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bjorn Andersson]

On Mon, Jan 22, 2024 at 07:21:58PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> 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.

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

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

> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
>  arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
>  2 files changed, 128 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> index cd0db4f31d4a..c9b1600c57ef 100644
> --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> @@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
>  		regulator-always-on;
>  	};
>  
> +	qca6390_pmu: pmu@0 {

This is not a thing.

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

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?

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

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

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

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

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Dmitry Baryshkov]

On Mon, 22 Jan 2024 at 20:22, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> 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 <bartosz.golaszewski@linaro.org>

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.

> ---
>  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
>  arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
>  2 files changed, 128 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> index cd0db4f31d4a..c9b1600c57ef 100644
> --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> @@ -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>;
> +
> +               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>;
> +               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.

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

-- 
With best wishes
Dmitry

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Krzysztof Kozlowski]

On 22/01/2024 19:21, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> 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 <bartosz.golaszewski@linaro.org>

Please provide lore link to the binding.

Best regards,
Krzysztof

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 5:47 AM Bjorn Andersson <andersson@kernel.org> wrote:
>
> On Mon, Jan 22, 2024 at 07:21:58PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > 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.

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

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.

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

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.

> So what you need to do is describe why the pads suddenly changed.
>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
> >  arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
> >  2 files changed, 128 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > index cd0db4f31d4a..c9b1600c57ef 100644
> > --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > @@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
> >               regulator-always-on;
> >       };
> >
> > +     qca6390_pmu: pmu@0 {
>
> This is not a thing.
>

What isn't?

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

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

I'm not following. Why?

>
> > +                     };
> [..]
> > @@ -734,6 +816,24 @@ &pcie0_phy {
> >       vdda-pll-supply = <&vreg_l9a_1p2>;
> >  };
> >
> > +&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

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

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 6:54 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Mon, 22 Jan 2024 at 20:22, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > 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 <bartosz.golaszewski@linaro.org>
>
> 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.
>

This is irrelevant for the HW representation though - which is what
I'm trying to figure out first.

As I said under the previous discussion: I don't plan to use the
regulator framework here. Instead, the regulator phandles will be used
by the new pwrseq subsystem to retrieve the handle to the correct
pwrseq context structure.

But even so: I doubt this is the first time something like this is
used: PMICs take supplies all the time and expose their own
regulators. I wouldn't stress about it.

[snip]

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

What alternative do you propose?

Bart

> > +       };
> > +};
> > +
> >  &pcie1 {
> >         status = "okay";
> >  };
>
> --
> With best wishes
> Dmitry

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 9:30 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 22/01/2024 19:21, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > 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 <bartosz.golaszewski@linaro.org>
>
> 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

Bart

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Krzysztof Kozlowski]

On 23/01/2024 11:04, Bartosz Golaszewski wrote:
> On Tue, Jan 23, 2024 at 9:30 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 22/01/2024 19:21, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>
>>> 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 <bartosz.golaszewski@linaro.org>
>>
>> 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

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


Best regards,
Krzysztof

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 4:09 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 23/01/2024 11:04, Bartosz Golaszewski wrote:
> > On Tue, Jan 23, 2024 at 9:30 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 22/01/2024 19:21, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>>
> >>> 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 <bartosz.golaszewski@linaro.org>
> >>
> >> 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
>
> This does not describe your PMU node. Maybe lack of the binding was
> intentional? In such case I missed it from commit msg...
>

Ah, I thought you were asking about the existing bluetooth binding.
Yes, I intentionally didn't include any new bindings as my question
is: does this device-tree source change make sense? If so, then I'll
include it in my series and build the bindings and C code around it.

Bartosz

Re: Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bjorn Andersson]

On Tue, Jan 23, 2024 at 10:22:33AM +0100, Bartosz Golaszewski wrote:
> On Tue, Jan 23, 2024 at 5:47 AM Bjorn Andersson <andersson@kernel.org> wrote:
> >
> > On Mon, Jan 22, 2024 at 07:21:58PM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > 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.
> 
> > 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.
> >
> > > 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.
> >
> 
> 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".

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

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

> > > 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.
> >
> 
> 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?

> 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.
> 
> > So what you need to do is describe why the pads suddenly changed.
> >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
> > >  arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
> > >  2 files changed, 128 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > > index cd0db4f31d4a..c9b1600c57ef 100644
> > > --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
> > > @@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
> > >               regulator-always-on;
> > >       };
> > >
> > > +     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".

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

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

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

> >
> > > +                     };
> > [..]
> > > @@ -734,6 +816,24 @@ &pcie0_phy {
> > >       vdda-pll-supply = <&vreg_l9a_1p2>;
> > >  };
> > >
> > > +&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.
> 

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

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

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Krzysztof Kozlowski]

On 23/01/2024 16:34, Bjorn Andersson wrote:
> On Tue, Jan 23, 2024 at 10:22:33AM +0100, Bartosz Golaszewski wrote:
>> On Tue, Jan 23, 2024 at 5:47 AM Bjorn Andersson <andersson@kernel.org> wrote:
>>>
>>> On Mon, Jan 22, 2024 at 07:21:58PM +0100, Bartosz Golaszewski wrote:
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> 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.
>>
>>> 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.
>>>
>>>> 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.
>>>
>>
>> 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".
> 
>> 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.
> 
>> 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?

While the board does not have, the board schematics have it, e.g. RB5.
Also QCA datasheet (at least the one on RB5) describes relationships
between the external supplies, feeding PMU in my understanding, and
internal supplies, coming from PMU to specific blocks.

Best regards,
Krzysztof

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[neil.armstrong]

On 23/01/2024 16:34, Bjorn Andersson wrote:
> On Tue, Jan 23, 2024 at 10:22:33AM +0100, Bartosz Golaszewski wrote:
>> On Tue, Jan 23, 2024 at 5:47 AM Bjorn Andersson <andersson@kernel.org> wrote:
>>>
>>> On Mon, Jan 22, 2024 at 07:21:58PM +0100, Bartosz Golaszewski wrote:
>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>
>>>> 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.
>>
>>> 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.
>>>
>>>> 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.
>>>
>>
>> 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".
> 
>> 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.
> 
>> 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?
> 
>>>> 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.
>>>
>>
>> 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?
> 
>> 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.
>>
>>> So what you need to do is describe why the pads suddenly changed.
>>>
>>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>> ---
>>>>   arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 129 +++++++++++++++++++++--
>>>>   arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
>>>>   2 files changed, 128 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
>>>> index cd0db4f31d4a..c9b1600c57ef 100644
>>>> --- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
>>>> @@ -108,6 +108,88 @@ lt9611_3v3: lt9611-3v3 {
>>>>                regulator-always-on;
>>>>        };
>>>>
>>>> +     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".
> 
>>>> +             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>;
>>>
>>> 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.
>>
> 
> Per Dmitry's argument that you linked above, bt-enable and wifi-enable
> should be the only things that you need to synchronize.
> 
>>>> +
>>>> +             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...
>>
>> 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

> 
>>>
>>>> +                     };
>>> [..]
>>>> @@ -734,6 +816,24 @@ &pcie0_phy {
>>>>        vdda-pll-supply = <&vreg_l9a_1p2>;
>>>>   };
>>>>
>>>> +&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.
>>
> 
> 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
> 
>> Bart
>>
>>>> +             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>;
>>>> +             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
> 

Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 4:49 PM <neil.armstrong@linaro.org> wrote:
>

[snip]

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

To be precise: it's page 33 of the QCA6391 datasheet and it defines
"power inputs from host" and "LDO power outputs" with different
voltages.

Bart

[snip]

Re: Re: [RFC] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

[Bartosz Golaszewski]

On Tue, Jan 23, 2024 at 4:34 PM Bjorn Andersson <andersson@kernel.org> wrote:
>

[snip]

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

I really wanted to limit the discussion to how the device-tree will
look like. I will provide a PoC of the full framework soon.

And the PCI power sequencing will keep on being its own thing - this
time using the global pwrseq as the lower-level abstraction.

Bart