| Message ID | 20241010132902.2882939-1-quic_miaoqing@quicinc.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v4] arm64: dts: qcom: sa8775p-ride: add WiFi/BT nodes | expand |
On Thu, Oct 10, 2024 at 09:29:02PM 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> > --- > v2: > - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". > - relocate pcieport0 node in alphabetical order. > v3: > - add 'qcom,ath11k-calibration-variant = "SA8775P"'. > v4: > - update 'ath11k-calibration-variant' to "Ride". What exactly is Ride? Is there just one Ride board? I thought it's a board family name. Also, could you please extend the commit message with messages from the ath11k driver, showing the chip_id / board_id ?
On 10/10/2024 9:47 PM, Dmitry Baryshkov wrote: > On Thu, Oct 10, 2024 at 09:29:02PM 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> >> --- >> v2: >> - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". >> - relocate pcieport0 node in alphabetical order. >> v3: >> - add 'qcom,ath11k-calibration-variant = "SA8775P"'. >> v4: >> - update 'ath11k-calibration-variant' to "Ride". > > What exactly is Ride? Is there just one Ride board? I thought it's a > board family name. I just follow the existing boards, 'Ride' is a board name. Both 'Ride' and 'Ride r3' boards are attached with WCN6855 WLAN chip. arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts:1112: qcom,ath11k-calibration-variant = "Fairphone_5"; arch/arm64/boot/dts/qcom/qcm6490-shift-otter.dts:958: qcom,ath11k-calibration-variant = "SHIFTphone_8"; arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts:879: qcom,ath11k-calibration-variant = "LE_X13S"; > > Also, could you please extend the commit message with messages from the > ath11k driver, showing the chip_id / board_id ? The board-id is non 0xff, do you still think we need to add 'qcom,ath11k-calibration-variant', following is the WLAN chip board data info, bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=519.bin
On Thu, Oct 10, 2024 at 09:59:11PM GMT, Miaoqing Pan wrote: > > > On 10/10/2024 9:47 PM, Dmitry Baryshkov wrote: > > On Thu, Oct 10, 2024 at 09:29:02PM 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> > > > --- > > > v2: > > > - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". > > > - relocate pcieport0 node in alphabetical order. > > > v3: > > > - add 'qcom,ath11k-calibration-variant = "SA8775P"'. > > > v4: > > > - update 'ath11k-calibration-variant' to "Ride". > > > > What exactly is Ride? Is there just one Ride board? I thought it's a > > board family name. > > I just follow the existing boards, 'Ride' is a board name. Both 'Ride' and > 'Ride r3' boards are attached with WCN6855 WLAN chip. > > arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts:1112: > qcom,ath11k-calibration-variant = "Fairphone_5"; > arch/arm64/boot/dts/qcom/qcm6490-shift-otter.dts:958: > qcom,ath11k-calibration-variant = "SHIFTphone_8"; > arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts:879: > qcom,ath11k-calibration-variant = "LE_X13S"; There definitely are other Ride boards. I see patches related to qcs8300-ride. Does that board use the same BDF file? If not, Qualcomm_SA8775P_Ride or QC_SA8775P_Ride sounds like a better approach. > > > > Also, could you please extend the commit message with messages from the > > ath11k driver, showing the chip_id / board_id ? > > The board-id is non 0xff, do you still think we need to add > 'qcom,ath11k-calibration-variant', following is the WLAN chip board data > info, > > bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=519.bin I'd ask Kalle / Jeff to answer this question. Are we sure that this board-id won't be reused by any else device?
On 10/10/2024 10:40 PM, Dmitry Baryshkov wrote: > On Thu, Oct 10, 2024 at 09:59:11PM GMT, Miaoqing Pan wrote: >> >> >> On 10/10/2024 9:47 PM, Dmitry Baryshkov wrote: >>> On Thu, Oct 10, 2024 at 09:29:02PM 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> >>>> --- >>>> v2: >>>> - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". >>>> - relocate pcieport0 node in alphabetical order. >>>> v3: >>>> - add 'qcom,ath11k-calibration-variant = "SA8775P"'. >>>> v4: >>>> - update 'ath11k-calibration-variant' to "Ride". >>> >>> What exactly is Ride? Is there just one Ride board? I thought it's a >>> board family name. >> >> I just follow the existing boards, 'Ride' is a board name. Both 'Ride' and >> 'Ride r3' boards are attached with WCN6855 WLAN chip. >> >> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts:1112: >> qcom,ath11k-calibration-variant = "Fairphone_5"; >> arch/arm64/boot/dts/qcom/qcm6490-shift-otter.dts:958: >> qcom,ath11k-calibration-variant = "SHIFTphone_8"; >> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts:879: >> qcom,ath11k-calibration-variant = "LE_X13S"; > > There definitely are other Ride boards. I see patches related to > qcs8300-ride. Does that board use the same BDF file? If not, > Qualcomm_SA8775P_Ride or QC_SA8775P_Ride sounds like a better approach. > QCS8300 and SA8775P both use the same WiFi card, so the same BDF file will be used. The extra variant will increase the size of board-2.bin. Anyway, the calibration variant is no other side effects. >>> >>> Also, could you please extend the commit message with messages from the >>> ath11k driver, showing the chip_id / board_id ? >> >> The board-id is non 0xff, do you still think we need to add >> 'qcom,ath11k-calibration-variant', following is the WLAN chip board data >> info, >> >> bus=pci,vendor=17cb,device=1103,subsystem-vendor=17cb,subsystem-device=0108,qmi-chip-id=2,qmi-board-id=519.bin > > I'd ask Kalle / Jeff to answer this question. Are we sure that this > board-id won't be reused by any else device? >
Miaoqing Pan <quic_miaoqing@quicinc.com> writes: > On 10/10/2024 10:40 PM, Dmitry Baryshkov wrote: >> On Thu, Oct 10, 2024 at 09:59:11PM GMT, Miaoqing Pan wrote: >>> >>> >>> On 10/10/2024 9:47 PM, Dmitry Baryshkov wrote: >>>> On Thu, Oct 10, 2024 at 09:29:02PM 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> >>>>> --- >>>>> v2: >>>>> - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". >>>>> - relocate pcieport0 node in alphabetical order. >>>>> v3: >>>>> - add 'qcom,ath11k-calibration-variant = "SA8775P"'. >>>>> v4: >>>>> - update 'ath11k-calibration-variant' to "Ride". >>>> >>>> What exactly is Ride? Is there just one Ride board? I thought it's a >>>> board family name. >>> >>> I just follow the existing boards, 'Ride' is a board name. Both 'Ride' and >>> 'Ride r3' boards are attached with WCN6855 WLAN chip. >>> >>> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts:1112: >>> qcom,ath11k-calibration-variant = "Fairphone_5"; >>> arch/arm64/boot/dts/qcom/qcm6490-shift-otter.dts:958: >>> qcom,ath11k-calibration-variant = "SHIFTphone_8"; >>> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts:879: >>> qcom,ath11k-calibration-variant = "LE_X13S"; >> There definitely are other Ride boards. I see patches related to >> qcs8300-ride. Does that board use the same BDF file? If not, >> Qualcomm_SA8775P_Ride or QC_SA8775P_Ride sounds like a better approach. >> > > QCS8300 and SA8775P both use the same WiFi card, so the same BDF file > will be used. The extra variant will increase the size of board-2.bin. In board-2.bin one board file can have multiple names, that was designed exactly for cases like this. So the memory inrease is just the size of string (plus few bytes for the TLV headers). Dmitry is correct here. It's much better to have unique names instead trying reuse the same names for different hardware. For example, if later we actually need different board files then that's simple to do just in board-2.bin.
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi index 0c1b21def4b6..c41fac1eb6c2 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,wcn6855-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"; @@ -702,6 +793,25 @@ &pcie1_phy { status = "okay"; }; +&pcieport0 { + wifi@0 { + compatible = "pci17cb,1101"; + reg = <0x10000 0x0 0x0 0x0 0x0>; + + qcom,ath11k-calibration-variant = "Ride"; + + 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>; + }; +}; + &remoteproc_adsp { firmware-name = "qcom/sa8775p/adsp.mbn"; status = "okay"; @@ -744,6 +854,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 { 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> --- v2: - fix wcn6855-pmu compatible to "qcom,wcn6855-pmu". - relocate pcieport0 node in alphabetical order. v3: - add 'qcom,ath11k-calibration-variant = "SA8775P"'. v4: - update 'ath11k-calibration-variant' to "Ride". --- arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 121 +++++++++++++++++++++ arch/arm64/boot/dts/qcom/sa8775p.dtsi | 2 +- 2 files changed, 122 insertions(+), 1 deletion(-)