On 30/01/2025 11:12, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
>> On 29/01/2025 04:43, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
>>>> On 28/01/2025 07:52, Ping-Ke Shih wrote:
>>>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
>>>>>> On 27/01/2025 08:36, Ping-Ke Shih wrote:
>>>>>>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> 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@xxxxxxxxx>
>>>>>>>> ---
>>>>>>>> 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.
>
Oh, yes, the switching is done only in the USB probe function.
