diff mbox series

[v5,09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391

Message ID 20240216203215.40870-10-brgl@bgdev.pl (mailing list archive)
State Not Applicable
Delegated to: Kalle Valo
Headers show
Series power: sequencing: implement the subsystem and add first users | expand

Commit Message

Bartosz Golaszewski Feb. 16, 2024, 8:32 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add a node for the PMU module of the QCA6391 present on the RB5 board.
Assign its LDO power outputs to the existing Bluetooth module. Add a
node for the PCIe port to sm8250.dtsi and define the WLAN node on it in
the board's .dts and also make it consume the power outputs of the PMU.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 123 +++++++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8250.dtsi     |  10 ++
 2 files changed, 122 insertions(+), 11 deletions(-)

Comments

Mark Brown Feb. 19, 2024, 6:03 p.m. UTC | #1
On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:

> +			vreg_pmu_aon_0p59: ldo1 {
> +				regulator-name = "vreg_pmu_aon_0p59";
> +				regulator-min-microvolt = <540000>;
> +				regulator-max-microvolt = <840000>;
> +			};

That's a *very* wide voltage range for a supply that's got a name ending
in _0_p59 which sounds a lot like it should be fixed at 0.59V.
Similarly for a bunch of the other supplies, and I'm not seeing any
evidence that the consumers do any voltage changes here?  There doesn't
appear to be any logic here, I'm not convinced these are validated or
safe constraints.
Bartosz Golaszewski Feb. 19, 2024, 6:48 p.m. UTC | #2
On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
>
> > +                     vreg_pmu_aon_0p59: ldo1 {
> > +                             regulator-name = "vreg_pmu_aon_0p59";
> > +                             regulator-min-microvolt = <540000>;
> > +                             regulator-max-microvolt = <840000>;
> > +                     };
>
> That's a *very* wide voltage range for a supply that's got a name ending
> in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> Similarly for a bunch of the other supplies, and I'm not seeing any
> evidence that the consumers do any voltage changes here?  There doesn't
> appear to be any logic here, I'm not convinced these are validated or
> safe constraints.

No, the users don't request any regulators (or rather: software
representations thereof) because - as per the cover letter - no
regulators are created by the PMU driver. This is what is physically
on the board - as the schematics and the datasheet define it. I took
the values from the docs verbatim. In C, we create a power sequencing
provider which doesn't use the regulator framework at all.

Bartosz
Mark Brown Feb. 19, 2024, 7:59 p.m. UTC | #3
On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:

> > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > +                             regulator-min-microvolt = <540000>;
> > > +                             regulator-max-microvolt = <840000>;
> > > +                     };

> > That's a *very* wide voltage range for a supply that's got a name ending
> > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > Similarly for a bunch of the other supplies, and I'm not seeing any
> > evidence that the consumers do any voltage changes here?  There doesn't
> > appear to be any logic here, I'm not convinced these are validated or
> > safe constraints.

> No, the users don't request any regulators (or rather: software
> representations thereof) because - as per the cover letter - no
> regulators are created by the PMU driver. This is what is physically
> on the board - as the schematics and the datasheet define it. I took

The above makes no sense.  How can constraints be "what is physically on
the board", particularly variable constrants when there isn't even a
consumer?  What values are you taking from which documentation?  

The cover letter and binding both claimed (buried after large amounts of
changelog) that these PMUs were exposing regulators to consumers and the
DTS puports to do exactly that...

> the values from the docs verbatim. In C, we create a power sequencing
> provider which doesn't use the regulator framework at all.

For something that doesn't use the regulator framework at all what
appears to be a provider in patch 16 ("power: pwrseq: add a driver for
the QCA6390 PMU module") seems to have a lot of regualtor API calls?
Bartosz Golaszewski Feb. 20, 2024, 11:16 a.m. UTC | #4
On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
>
> > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > +                             regulator-min-microvolt = <540000>;
> > > > +                             regulator-max-microvolt = <840000>;
> > > > +                     };
>
> > > That's a *very* wide voltage range for a supply that's got a name ending

Because it's an error, it should have been 640000. Thanks for spotting it.

> > > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > > Similarly for a bunch of the other supplies, and I'm not seeing any
> > > evidence that the consumers do any voltage changes here?  There doesn't
> > > appear to be any logic here, I'm not convinced these are validated or
> > > safe constraints.
>
> > No, the users don't request any regulators (or rather: software
> > representations thereof) because - as per the cover letter - no
> > regulators are created by the PMU driver. This is what is physically
> > on the board - as the schematics and the datasheet define it. I took
>
> The above makes no sense.  How can constraints be "what is physically on
> the board", particularly variable constrants when there isn't even a
> consumer?  What values are you taking from which documentation?
>

The operating conditions for PMU outputs. I took them from a
confidential datasheet. There's a table for input constraints and
possible output values.

And what do you mean by there not being any consumers? The WLAN and BT
*are* the consumers.

> The cover letter and binding both claimed (buried after large amounts of
> changelog) that these PMUs were exposing regulators to consumers and the
> DTS puports to do exactly that...
>

Yes, but I'm not sure what the question is.

> > the values from the docs verbatim. In C, we create a power sequencing
> > provider which doesn't use the regulator framework at all.
>
> For something that doesn't use the regulator framework at all what
> appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> the QCA6390 PMU module") seems to have a lot of regualtor API calls?

This driver is a power sequencing *provider* but also a regulator
*consumer*. It gets regulators from the host and exposes a power
sequencer to *its* consumers (WLAN and BT). On DT it exposes
regulators (LDO outputs of the PMU) but we don't instantiate them in
C.

Bart
Mark Brown Feb. 20, 2024, 1:31 p.m. UTC | #5
On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:

> > > No, the users don't request any regulators (or rather: software
> > > representations thereof) because - as per the cover letter - no
> > > regulators are created by the PMU driver. This is what is physically
> > > on the board - as the schematics and the datasheet define it. I took

> > The above makes no sense.  How can constraints be "what is physically on
> > the board", particularly variable constrants when there isn't even a
> > consumer?  What values are you taking from which documentation?

> The operating conditions for PMU outputs. I took them from a
> confidential datasheet. There's a table for input constraints and
> possible output values.

That sounds like you're just putting the maximum range of voltages that
the PMU can output in there.  This is a fundamental misunderstanding of
what the constraints are for, the constraints exist to specify what is
safe on a specific board which will in essentially all cases be much
more restricted.  The regulator driver should describe whatever the PMU
can support by itself, the constraints whatever is actually safe and
functional on the specific board.

> And what do you mean by there not being any consumers? The WLAN and BT
> *are* the consumers.

There are no drivers that bind to the regulators and vary the voltages
at runtime.

> > > the values from the docs verbatim. In C, we create a power sequencing
> > > provider which doesn't use the regulator framework at all.

> > For something that doesn't use the regulator framework at all what
> > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > the QCA6390 PMU module") seems to have a lot of regualtor API calls?

> This driver is a power sequencing *provider* but also a regulator
> *consumer*. It gets regulators from the host and exposes a power
> sequencer to *its* consumers (WLAN and BT). On DT it exposes
> regulators (LDO outputs of the PMU) but we don't instantiate them in
> C.

Right, which sounds a lot like being a user of the regualtor framework.
Bartosz Golaszewski Feb. 20, 2024, 1:38 p.m. UTC | #6
On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
>
> > > > No, the users don't request any regulators (or rather: software
> > > > representations thereof) because - as per the cover letter - no
> > > > regulators are created by the PMU driver. This is what is physically
> > > > on the board - as the schematics and the datasheet define it. I took
>
> > > The above makes no sense.  How can constraints be "what is physically on
> > > the board", particularly variable constrants when there isn't even a
> > > consumer?  What values are you taking from which documentation?
>
> > The operating conditions for PMU outputs. I took them from a
> > confidential datasheet. There's a table for input constraints and
> > possible output values.
>
> That sounds like you're just putting the maximum range of voltages that
> the PMU can output in there.  This is a fundamental misunderstanding of
> what the constraints are for, the constraints exist to specify what is
> safe on a specific board which will in essentially all cases be much
> more restricted.  The regulator driver should describe whatever the PMU
> can support by itself, the constraints whatever is actually safe and
> functional on the specific board.
>

Ok, got it. Yeah I misunderstood that, but I think it's maybe the
second or third time I'm adding a regulators node myself to DT. I'll
change that.

> > And what do you mean by there not being any consumers? The WLAN and BT
> > *are* the consumers.
>
> There are no drivers that bind to the regulators and vary the voltages
> at runtime.
>

Even with the above misunderstanding clarified: so what? DT is the
representation of hardware. There's nothing that obligates us to model
DT sources in drivers 1:1.

> > > > the values from the docs verbatim. In C, we create a power sequencing
> > > > provider which doesn't use the regulator framework at all.
>
> > > For something that doesn't use the regulator framework at all what
> > > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > > the QCA6390 PMU module") seems to have a lot of regualtor API calls?
>
> > This driver is a power sequencing *provider* but also a regulator
> > *consumer*. It gets regulators from the host and exposes a power
> > sequencer to *its* consumers (WLAN and BT). On DT it exposes
> > regulators (LDO outputs of the PMU) but we don't instantiate them in
> > C.
>
> Right, which sounds a lot like being a user of the regualtor framework.

Ok, I meant "user" as a regulator provider but maybe I wasn't clear enough.

Bart
Mark Brown Feb. 20, 2024, 1:48 p.m. UTC | #7
On Tue, Feb 20, 2024 at 02:38:33PM +0100, Bartosz Golaszewski wrote:
> On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:

> > > And what do you mean by there not being any consumers? The WLAN and BT
> > > *are* the consumers.

> > There are no drivers that bind to the regulators and vary the voltages
> > at runtime.

> Even with the above misunderstanding clarified: so what? DT is the
> representation of hardware. There's nothing that obligates us to model
> DT sources in drivers 1:1.

It is generally a bad sign if there is a voltage range specified on a
regulator that's not got any indication that the voltage is going to be
actively managed, especially in situations like with several of the
supplies the DT was specifying where there are clear indications that
the supply is intended to be fixed voltage (or cases where every single
supply has a voltage range which would be highly unusual).  Looking at
the consumers might provide an explanation for such unusual and likely
incorrect constraints, and the lack of any consumers in conjunction with 
other warning signs reenforces those warning signs.
Bartosz Golaszewski Feb. 20, 2024, 1:51 p.m. UTC | #8
On Tue, Feb 20, 2024 at 2:48 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Feb 20, 2024 at 02:38:33PM +0100, Bartosz Golaszewski wrote:
> > On Tue, Feb 20, 2024 at 2:31 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Tue, Feb 20, 2024 at 12:16:10PM +0100, Bartosz Golaszewski wrote:
>
> > > > And what do you mean by there not being any consumers? The WLAN and BT
> > > > *are* the consumers.
>
> > > There are no drivers that bind to the regulators and vary the voltages
> > > at runtime.
>
> > Even with the above misunderstanding clarified: so what? DT is the
> > representation of hardware. There's nothing that obligates us to model
> > DT sources in drivers 1:1.
>
> It is generally a bad sign if there is a voltage range specified on a
> regulator that's not got any indication that the voltage is going to be
> actively managed, especially in situations like with several of the
> supplies the DT was specifying where there are clear indications that
> the supply is intended to be fixed voltage (or cases where every single
> supply has a voltage range which would be highly unusual).  Looking at
> the consumers might provide an explanation for such unusual and likely
> incorrect constraints, and the lack of any consumers in conjunction with
> other warning signs reenforces those warning signs.

What do you recommend? No values at all in these regulators as it's
the PMU which will manage those on its own once powered up by the host
PMIC?

Bartosz
Mark Brown Feb. 20, 2024, 2:10 p.m. UTC | #9
On Tue, Feb 20, 2024 at 02:51:25PM +0100, Bartosz Golaszewski wrote:
> On Tue, Feb 20, 2024 at 2:48 PM Mark Brown <broonie@kernel.org> wrote:

> > It is generally a bad sign if there is a voltage range specified on a
> > regulator that's not got any indication that the voltage is going to be
> > actively managed, especially in situations like with several of the
> > supplies the DT was specifying where there are clear indications that
> > the supply is intended to be fixed voltage (or cases where every single
> > supply has a voltage range which would be highly unusual).  Looking at
> > the consumers might provide an explanation for such unusual and likely
> > incorrect constraints, and the lack of any consumers in conjunction with
> > other warning signs reenforces those warning signs.

> What do you recommend? No values at all in these regulators as it's
> the PMU which will manage those on its own once powered up by the host
> PMIC?

Unless something is actively going to change the voltages at runtime
or Linux needs to set a specific voltage (in which case minimum and
maximum should be identical) there should be nothing specified.
Dmitry Baryshkov Feb. 20, 2024, 4:30 p.m. UTC | #10
On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> >
> > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > +                             regulator-min-microvolt = <540000>;
> > > > > +                             regulator-max-microvolt = <840000>;
> > > > > +                     };
> >
> > > > That's a *very* wide voltage range for a supply that's got a name ending
>
> Because it's an error, it should have been 640000. Thanks for spotting it.

According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
to 0.59V, which is the working voltage.

VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.

>
> > > > in _0_p59 which sounds a lot like it should be fixed at 0.59V.
> > > > Similarly for a bunch of the other supplies, and I'm not seeing any
> > > > evidence that the consumers do any voltage changes here?  There doesn't
> > > > appear to be any logic here, I'm not convinced these are validated or
> > > > safe constraints.
> >
> > > No, the users don't request any regulators (or rather: software
> > > representations thereof) because - as per the cover letter - no
> > > regulators are created by the PMU driver. This is what is physically
> > > on the board - as the schematics and the datasheet define it. I took
> >
> > The above makes no sense.  How can constraints be "what is physically on
> > the board", particularly variable constrants when there isn't even a
> > consumer?  What values are you taking from which documentation?
> >
>
> The operating conditions for PMU outputs. I took them from a
> confidential datasheet. There's a table for input constraints and
> possible output values.
>
> And what do you mean by there not being any consumers? The WLAN and BT
> *are* the consumers.
>
> > The cover letter and binding both claimed (buried after large amounts of
> > changelog) that these PMUs were exposing regulators to consumers and the
> > DTS puports to do exactly that...
> >
>
> Yes, but I'm not sure what the question is.
>
> > > the values from the docs verbatim. In C, we create a power sequencing
> > > provider which doesn't use the regulator framework at all.
> >
> > For something that doesn't use the regulator framework at all what
> > appears to be a provider in patch 16 ("power: pwrseq: add a driver for
> > the QCA6390 PMU module") seems to have a lot of regualtor API calls?
>
> This driver is a power sequencing *provider* but also a regulator
> *consumer*. It gets regulators from the host and exposes a power
> sequencer to *its* consumers (WLAN and BT). On DT it exposes
> regulators (LDO outputs of the PMU) but we don't instantiate them in
> C.
>
> Bart
Bartosz Golaszewski Feb. 20, 2024, 5:53 p.m. UTC | #11
On Tue, Feb 20, 2024 at 5:30 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > >
> > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> > >
> > > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > > +                             regulator-min-microvolt = <540000>;
> > > > > > +                             regulator-max-microvolt = <840000>;
> > > > > > +                     };
> > >
> > > > > That's a *very* wide voltage range for a supply that's got a name ending
> >
> > Because it's an error, it should have been 640000. Thanks for spotting it.
>
> According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
> to 0.59V, which is the working voltage.
>

Hmm indeed this is what figure 3.4 says but table 3-2 says the maximum is 0.64V.

> VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.
>

Again figure 3.4 and table 3-2 disagree unless I'm missing something.

Bart

[snip]
Dmitry Baryshkov Feb. 20, 2024, 6:11 p.m. UTC | #12
On Tue, 20 Feb 2024 at 19:53, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Tue, Feb 20, 2024 at 5:30 PM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > On Tue, 20 Feb 2024 at 13:16, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > On Mon, Feb 19, 2024 at 8:59 PM Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote:
> > > > > On Mon, Feb 19, 2024 at 7:03 PM Mark Brown <broonie@kernel.org> wrote:
> > > > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote:
> > > >
> > > > > > > +                     vreg_pmu_aon_0p59: ldo1 {
> > > > > > > +                             regulator-name = "vreg_pmu_aon_0p59";
> > > > > > > +                             regulator-min-microvolt = <540000>;
> > > > > > > +                             regulator-max-microvolt = <840000>;
> > > > > > > +                     };
> > > >
> > > > > > That's a *very* wide voltage range for a supply that's got a name ending
> > >
> > > Because it's an error, it should have been 640000. Thanks for spotting it.
> >
> > According to the datasheet, VDD08_PMU_AON_O goes up to 0.85V then down
> > to 0.59V, which is the working voltage.
> >
>
> Hmm indeed this is what figure 3.4 says but table 3-2 says the maximum is 0.64V.
>
> > VDD08_PMU_RFA_CMN is normally at 0.8V, but goes to 0.4V during sleep.
> >
>
> Again figure 3.4 and table 3-2 disagree unless I'm missing something.

I suspect that the table you have mentioned provides normal working
conditions for the PMU, while power-up and sleep might be outside of
'normal' conditions.

I suppose that these outputs are underspecified in the datasheet. I
think we can omit the values here.
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index cd0db4f31d4a..3331a3e5aaa8 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -108,6 +108,87 @@  lt9611_3v3: lt9611-3v3 {
 		regulator-always-on;
 	};
 
+	qca6390-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>;
+		vddrfa0p95-supply = <&vreg_s2f_0p95>;
+		vddrfa1p3-supply = <&vreg_s8c_1p3>;
+		vddrfa1p9-supply = <&vreg_s5a_1p9>;
+		vddpcie1p3-supply = <&vreg_s8c_1p3>;
+		vddpcie1p9-supply = <&vreg_s5a_1p9>;
+		vddio-supply = <&vreg_s4a_1p8>;
+
+		wlan-enable-gpios = <&tlmm 20 GPIO_ACTIVE_HIGH>;
+		bt-enable-gpios = <&tlmm 21 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 +815,23 @@  &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>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+	};
+};
+
 &pcie1 {
 	status = "okay";
 };
@@ -1303,6 +1401,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 +1417,12 @@  &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>;
+		vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+		vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index f3c70b87efad..29d2ccb5b389 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2203,6 +2203,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 {