| Message ID | 20240905064817.3885953-1-quic_miaoqing@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: dts: qcom: sa8775p-ride: add WiFi/BT nodes | expand |
On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> > --- > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- > 2 files changed, 120 insertions(+), 1 deletion(-) > > @@ -837,3 +939,20 @@ &usb_2_hsphy { > &xo_board_clk { > clock-frequency = <38400000>; > }; > + > +&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>; Please add qcom,ath11k-calibration-variant = "name"; > + }; > +};
On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: >> Add a node for the PMU module of the WCN6855 present on the sa8775p-ride >> board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. >> >> Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ >> arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- >> 2 files changed, 120 insertions(+), 1 deletion(-) >> >> @@ -837,3 +939,20 @@ &usb_2_hsphy { >> &xo_board_clk { >> clock-frequency = <38400000>; >> }; >> + >> +&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>; > > Please add > > qcom,ath11k-calibration-variant = "name"; No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver.
On Fri, Sep 06, 2024 at 08:19:28AM GMT, Miaoqing Pan wrote: > > > On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: > > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: > > > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride > > > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. > > > > > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> > > > --- > > > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ > > > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- > > > 2 files changed, 120 insertions(+), 1 deletion(-) > > > > > > @@ -837,3 +939,20 @@ &usb_2_hsphy { > > > &xo_board_clk { > > > clock-frequency = <38400000>; > > > }; > > > + > > > +&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>; > > > > Please add > > > > qcom,ath11k-calibration-variant = "name"; > > No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver. NAK, nodes describe hardware, not drivers. And we have had enough issues with the WCN wifi having collisions on the board-id / chip-id / etc. Maybe we should make calibration-data required for the DT-based systems? Kalle, WDYT?
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > On Fri, Sep 06, 2024 at 08:19:28AM GMT, Miaoqing Pan wrote: > >> >> >> On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: >> > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: >> > > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride >> > > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. >> > > >> > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> >> > > --- >> > > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ >> > > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- >> > > 2 files changed, 120 insertions(+), 1 deletion(-) >> > > >> > > @@ -837,3 +939,20 @@ &usb_2_hsphy { >> > > &xo_board_clk { >> > > clock-frequency = <38400000>; >> > > }; >> > > + >> > > +&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>; >> > >> > Please add >> > >> > qcom,ath11k-calibration-variant = "name"; >> >> No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver. > > NAK, nodes describe hardware, not drivers. And we have had enough issues > with the WCN wifi having collisions on the board-id / chip-id / etc. > > Maybe we should make calibration-data required for the DT-based systems? > Kalle, WDYT? I don't know exactly what hardware you are referring so this is just a quick and vague answer, take all this as grain of salt. I don't have any numbers but I'm assuming most of the ath10k/ath11k/ath12k devices have the calibration data stored in OTP inside the chip. There are also devices which store the calibration outside the chip, for example in DT, but my understanding is that they are a minority. If we were to require that the calibration data needs to be in DT, and not use OTP at all, that would limit the on types of devices ath11k can be used. And I don't even know how we could easily extract the calibration data from OTP and it would be extra work for everyone. Honestly I don't really see any benefits from this, only negatives.
On Mon, 9 Sept 2024 at 14:31, Kalle Valo <kvalo@kernel.org> wrote: > > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > > > On Fri, Sep 06, 2024 at 08:19:28AM GMT, Miaoqing Pan wrote: > > > >> > >> > >> On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: > >> > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: > >> > > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride > >> > > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. > >> > > > >> > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> > >> > > --- > >> > > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ > >> > > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- > >> > > 2 files changed, 120 insertions(+), 1 deletion(-) > >> > > > >> > > @@ -837,3 +939,20 @@ &usb_2_hsphy { > >> > > &xo_board_clk { > >> > > clock-frequency = <38400000>; > >> > > }; > >> > > + > >> > > +&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>; > >> > > >> > Please add > >> > > >> > qcom,ath11k-calibration-variant = "name"; > >> > >> No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver. > > > > NAK, nodes describe hardware, not drivers. And we have had enough issues > > with the WCN wifi having collisions on the board-id / chip-id / etc. > > > > Maybe we should make calibration-data required for the DT-based systems? > > Kalle, WDYT? > > I don't know exactly what hardware you are referring so this is just a > quick and vague answer, take all this as grain of salt. > > I don't have any numbers but I'm assuming most of the > ath10k/ath11k/ath12k devices have the calibration data stored in OTP > inside the chip. There are also devices which store the calibration > outside the chip, for example in DT, but my understanding is that they > are a minority. Please excuse me, the comment was about the qcom,athNk-calibration-variant, the property used to identify the BDF within board-2.bin. Currently it is optional, which leads to developers omitting it. I think it's worth making it a required property for new DT devices, making sure that we don't have an issue with the plenty of boards programmed to use 0xff as the board_id. Or just using the same ID, but different BDF files.
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > On Mon, 9 Sept 2024 at 14:31, Kalle Valo <kvalo@kernel.org> wrote: > >> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: >> >> > On Fri, Sep 06, 2024 at 08:19:28AM GMT, Miaoqing Pan wrote: >> > >> >> >> >> >> >> On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: >> >> > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: >> >> > > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride >> >> > > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. >> >> > > >> >> > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> >> >> > > --- >> >> > > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ >> >> > > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- >> >> > > 2 files changed, 120 insertions(+), 1 deletion(-) >> >> > > >> >> > > @@ -837,3 +939,20 @@ &usb_2_hsphy { >> >> > > &xo_board_clk { >> >> > > clock-frequency = <38400000>; >> >> > > }; >> >> > > + >> >> > > +&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>; >> >> > >> >> > Please add >> >> > >> >> > qcom,ath11k-calibration-variant = "name"; >> >> >> >> No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver. >> > >> > NAK, nodes describe hardware, not drivers. And we have had enough issues >> > with the WCN wifi having collisions on the board-id / chip-id / etc. >> > >> > Maybe we should make calibration-data required for the DT-based systems? >> > Kalle, WDYT? >> >> I don't know exactly what hardware you are referring so this is just a >> quick and vague answer, take all this as grain of salt. >> >> I don't have any numbers but I'm assuming most of the >> ath10k/ath11k/ath12k devices have the calibration data stored in OTP >> inside the chip. There are also devices which store the calibration >> outside the chip, for example in DT, but my understanding is that they >> are a minority. > > Please excuse me, the comment was about the > qcom,athNk-calibration-variant Ah :) In case you were wondering, I was talking above about qcom,ath10k-calibration-data property which is the full calibration data, board files are not used at all in that case. So please ignore all that I said. > the property used to identify the BDF within board-2.bin. Currently > it is optional, which leads to developers omitting it. I think it's > worth making it a required property for new DT devices, making sure > that we don't have an issue with the plenty of boards programmed to > use 0xff as the board_id. Or just using the same ID, but different BDF > files. This is also a quick answer, the merge window is getting close and we are finalising the ath12k MLO support so not much free time right now. Some chipsets do provide unique information for the ath10k/ath11k/ath12k driver to choose the correct board file, but I guess they are mostly mobile chipsets. Though not even all mobile chipsets provide that, as you are painfully aware. For AP chipsets it seems to be a rule that they don't provide unique information to choose the board file and a variant field is always needed. So I think there is a point in your proposal. Backward compatibility is important but I think we already handle that, at least in ath11k, as it's first try with variant field and then without variant. But this needs more investigation on both ath11k and ath12k. I hope for ath10k we would not need to touch the driver anymore. Can we revisit this in few weeks, after MLO is in better shape, and maybe you could start a new thread?
On Mon, Sep 09, 2024 at 03:27:48PM GMT, Kalle Valo wrote: > Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > > > On Mon, 9 Sept 2024 at 14:31, Kalle Valo <kvalo@kernel.org> wrote: > > > >> > >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > >> > >> > On Fri, Sep 06, 2024 at 08:19:28AM GMT, Miaoqing Pan wrote: > >> > > >> >> > >> >> > >> >> On 9/5/2024 8:49 PM, Dmitry Baryshkov wrote: > >> >> > On Thu, Sep 05, 2024 at 02:48:17PM GMT, Miaoqing Pan wrote: > >> >> > > Add a node for the PMU module of the WCN6855 present on the sa8775p-ride > >> >> > > board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. > >> >> > > > >> >> > > Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> > >> >> > > --- > >> >> > > arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ > >> >> > > arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- > >> >> > > 2 files changed, 120 insertions(+), 1 deletion(-) > >> >> > > > >> >> > > @@ -837,3 +939,20 @@ &usb_2_hsphy { > >> >> > > &xo_board_clk { > >> >> > > clock-frequency = <38400000>; > >> >> > > }; > >> >> > > + > >> >> > > +&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>; > >> >> > > >> >> > Please add > >> >> > > >> >> > qcom,ath11k-calibration-variant = "name"; > >> >> > >> >> No need, here the WiFi node is for 'drivers/pci/pwrctl', not ath11k driver. > >> > > >> > NAK, nodes describe hardware, not drivers. And we have had enough issues > >> > with the WCN wifi having collisions on the board-id / chip-id / etc. > >> > > >> > Maybe we should make calibration-data required for the DT-based systems? > >> > Kalle, WDYT? > >> > >> I don't know exactly what hardware you are referring so this is just a > >> quick and vague answer, take all this as grain of salt. > >> > >> I don't have any numbers but I'm assuming most of the > >> ath10k/ath11k/ath12k devices have the calibration data stored in OTP > >> inside the chip. There are also devices which store the calibration > >> outside the chip, for example in DT, but my understanding is that they > >> are a minority. > > > > Please excuse me, the comment was about the > > qcom,athNk-calibration-variant > > Ah :) In case you were wondering, I was talking above about > qcom,ath10k-calibration-data property which is the full calibration > data, board files are not used at all in that case. So please ignore all > that I said. > > > the property used to identify the BDF within board-2.bin. Currently > > it is optional, which leads to developers omitting it. I think it's > > worth making it a required property for new DT devices, making sure > > that we don't have an issue with the plenty of boards programmed to > > use 0xff as the board_id. Or just using the same ID, but different BDF > > files. > > This is also a quick answer, the merge window is getting close and we > are finalising the ath12k MLO support so not much free time right now. > > Some chipsets do provide unique information for the ath10k/ath11k/ath12k > driver to choose the correct board file, but I guess they are mostly > mobile chipsets. Though not even all mobile chipsets provide that, as > you are painfully aware. For AP chipsets it seems to be a rule that they > don't provide unique information to choose the board file and a variant > field is always needed. So I think there is a point in your proposal. Ack, thanks :-) > > Backward compatibility is important but I think we already handle that, > at least in ath11k, as it's first try with variant field and then > without variant. But this needs more investigation on both ath11k and > ath12k. I hope for ath10k we would not need to touch the driver anymore. > > Can we revisit this in few weeks, after MLO is in better shape, and > maybe you could start a new thread? Sure. Let's agree that I'll send a patch after -rc1, if I don't forget about it.
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi index 0c1b21def4b6..e5977dea1594 100644 --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi @@ -27,6 +27,83 @@ aliases { chosen { stdout-path = "serial0:115200n8"; }; + + vreg_conn_1p8: vreg_conn_1p8 { + compatible = "regulator-fixed"; + regulator-name = "vreg_conn_1p8"; + startup-delay-us = <4000>; + enable-active-high; + gpio = <&pmm8654au_1_gpios 4 GPIO_ACTIVE_HIGH>; + }; + + vreg_conn_pa: vreg_conn_pa { + compatible = "regulator-fixed"; + regulator-name = "vreg_conn_pa"; + startup-delay-us = <4000>; + enable-active-high; + gpio = <&pmm8654au_1_gpios 6 GPIO_ACTIVE_HIGH>; + }; + + wcn6855-pmu { + compatible = "qcom,qca6390-pmu"; + + pinctrl-names = "default"; + pinctrl-0 = <&bt_en_state>, <&wlan_en_state>; + + vddio-supply = <&vreg_conn_pa>; + vddaon-supply = <&vreg_l2c>; + vddpmu-supply = <&vreg_conn_1p8>; + vddrfa0p95-supply = <&vreg_l2c>; + vddrfa1p3-supply = <&vreg_l6e>; + vddrfa1p9-supply = <&vreg_s5a>; + vddpcie1p3-supply = <&vreg_l6e>; + vddpcie1p9-supply = <&vreg_s5a>; + + bt-enable-gpios = <&pmm8654au_1_gpios 8 GPIO_ACTIVE_HIGH>; + wlan-enable-gpios = <&pmm8654au_1_gpios 7 GPIO_ACTIVE_HIGH>; + + regulators { + vreg_pmu_rfa_cmn: ldo0 { + regulator-name = "vreg_pmu_rfa_cmn"; + }; + + vreg_pmu_aon_0p59: ldo1 { + regulator-name = "vreg_pmu_aon_0p59"; + }; + + vreg_pmu_wlcx_0p8: ldo2 { + regulator-name = "vreg_pmu_wlcx_0p8"; + }; + + vreg_pmu_wlmx_0p85: ldo3 { + regulator-name = "vreg_pmu_wlmx_0p85"; + }; + + vreg_pmu_btcmx_0p85: ldo4 { + regulator-name = "vreg_pmu_btcmx_0p85"; + }; + + vreg_pmu_rfa_0p8: ldo5 { + regulator-name = "vreg_pmu_rfa_0p8"; + }; + + vreg_pmu_rfa_1p2: ldo6 { + regulator-name = "vreg_pmu_rfa_1p2"; + }; + + vreg_pmu_rfa_1p7: ldo7 { + regulator-name = "vreg_pmu_rfa_1p7"; + }; + + vreg_pmu_pcie_0p9: ldo8 { + regulator-name = "vreg_pmu_pcie_0p9"; + }; + + vreg_pmu_pcie_1p8: ldo9 { + regulator-name = "vreg_pmu_pcie_1p8"; + }; + }; + }; }; &apps_rsc { @@ -453,6 +530,20 @@ &pmm8654au_1_gpios { "USB2_PWR_EN", "USB2_FAULT"; + wlan_en_state: wlan-en-state { + pins = "gpio7"; + function = "normal"; + output-low; + bias-pull-down; + }; + + bt_en_state: bt-en-state { + pins = "gpio8"; + function = "normal"; + output-low; + bias-pull-down; + }; + usb2_en_state: usb2-en-state { pins = "gpio9"; function = "normal"; @@ -744,6 +835,17 @@ &uart17 { pinctrl-0 = <&qup_uart17_default>; pinctrl-names = "default"; status = "okay"; + + bluetooth { + compatible = "qcom,wcn6855-bt"; + + 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>; + }; }; &ufs_mem_hc { @@ -837,3 +939,20 @@ &usb_2_hsphy { &xo_board_clk { clock-frequency = <38400000>; }; + +&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>; + }; +}; diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/sa8775p.dtsi index e8dbc8d820a6..8d42b5e9c7d6 100644 --- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi @@ -5570,7 +5570,7 @@ pcie0: pcie@1c00000 { status = "disabled"; - pcie@0 { + pcieport0: pcie@0 { device_type = "pci"; reg = <0x0 0x0 0x0 0x0 0x0>; bus-range = <0x01 0xff>;
Add a node for the PMU module of the WCN6855 present on the sa8775p-ride board. Assign its LDO power outputs to the existing WiFi/Bluetooth module. Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> --- arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 119 +++++++++++++++++++++ arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- 2 files changed, 120 insertions(+), 1 deletion(-)