On Mon, 9 Sept 2024 at 14:31, Kalle Valo <kvalo@xxxxxxxxxx> wrote:
>
> Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> 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@xxxxxxxxxxx>
> >> > > ---
> >> > > 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.
--
With best wishes
Dmitry
