| Message ID | 20240216203215.40870-10-brgl@bgdev.pl (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | power: sequencing: implement the subsystem and add first users | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
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.
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
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?
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
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.
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
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.
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
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.
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
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]
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 --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 {