On Tue, Jan 23, 2024 at 6:54 AM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
>
> On Mon, 22 Jan 2024 at 20:22, Bartosz Golaszewski <brgl@xxxxxxxx> 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.
> >
> > 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@xxxxxxxxxx>
>
> 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
