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