Re: [PATCH 5/7] wifi: rtw88: Extend rtw_fw_send_ra_info() for RTL8814AU

[Ping-Ke Shih <pkshih@realtek.com>]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>On 29/01/2025 04:43, Ping-Ke Shih wrote:
>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>> On 28/01/2025 07:52, Ping-Ke Shih wrote:
>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>> On 27/01/2025 08:36, Ping-Ke Shih wrote:
>>>>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>>>>> The existing code is suitable for chips with up to 2 spatial streams.
>>>>>>> Inform the firmware about the rates it's allowed to use when
>>>>>>> transmitting 3 spatial streams.
>>>>>>>
>>>>>>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>>>>>>> ---
>>>>>>>  drivers/net/wireless/realtek/rtw88/fw.c | 14 ++++++++++++++
>>>>>>>  drivers/net/wireless/realtek/rtw88/fw.h |  1 +
>>>>>>>  2 files changed, 15 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
>>>>>>> index 02389b7c6876..0ca1b139110d 100644
>>>>>>> --- a/drivers/net/wireless/realtek/rtw88/fw.c
>>>>>>> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
>>>>>>> @@ -735,6 +735,7 @@ void rtw_fw_send_ra_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si,
>>>>>>>  {
>>>>>>>         u8 h2c_pkt[H2C_PKT_SIZE] = {0};
>>>>>>>         bool disable_pt = true;
>>>>>>> +       u32 mask_hi;
>>>>>>>
>>>>>>>         SET_H2C_CMD_ID_CLASS(h2c_pkt, H2C_CMD_RA_INFO);
>>>>>>>
>>>>>>> @@ -755,6 +756,19 @@ void rtw_fw_send_ra_info(struct rtw_dev *rtwdev, struct rtw_sta_info *si,
>>>>>>>         si->init_ra_lv = 0;
>>>>>>>
>>>>>>>         rtw_fw_send_h2c_command(rtwdev, h2c_pkt);
>>>>>>> +
>>>>>>> +       if (rtwdev->chip->rf_tbl[RF_PATH_C]) {
>>>>>>
>>>>>> Using `efuse->hw_cap.nss >= 3` would be consistent with latter patch.
>>>>>>
>>>>>
>>>>> I would like that, but nss is 2 when RTL8814AU is in USB 2 mode.
>>>>> I assume this is to keep the current draw under the 500 mA limit
>>>>> of USB 2.
>>>>>
>>>>> What about rtwdev->hal.rf_path_num >= 3 ? I don't remember why
>>>>> I didn't do that.
>>>>
>>>> I think `rtwdev->hal.rf_path_num >= 3` is suitable to initialize/configure
>>>> hardware registers, because no matter USB 2 or 3 mode should be the same.
>>>>
>>>> For this case (RA info), this is related to protocol, so I feel
>>>> `efuse->hw_cap.nss >= 3` is suitable, but I have not seen a patch to declare
>>>> supported NSS in register_hw(), or I missed it? Or, without RA_INFO_HI,
>>>> it gets abnormal rate to RTL8814AU in your test?
>>>>
>>>
>>> You didn't miss it, that will be in part 3. You can see the code here:
>>>
>>> https://github.com/lwfinger/rtw88/blob/21a3fa7ec11a0cbb3be14145f45cdca35c3d3217/rtw8814a.c#L82
>>>
>>
>> I feel we should clearly define the meaning. What I thought for 8814AU are:
>>  - hal->rf_type: hardware capability. Should be RF_3T3R no matter USB 2 or 3.
>>  - hal->antenna_tx: the antenna for current TX. Can be 2 antenna.
>>  - hal->antenna_rx: the antenna for current RX. Can be 2 antenna.
>>  - efuse->hw_cap.nss: read from efuse. So this will be 3SS for USB 2/3.
>> If you have better defnitiion, please share your ideas.
>>
>
> If efuse->hw_cap.nss is always 3, how to limit the spatial streams
> to 2 in USB 2 mode?

That's a proposal only, because I felt `efuse->hw_cap.nss` read from efuse
should be persistent, but it is fine to define desired meaning. 

I would like to confirm if USB devices will not switch USB 2/3 mode
after USB probe? If so, `efuse->hw_cap.nss` is also a kind of persistent.
Then, using `efuse->hw_cap.nss` seems fine.