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?
> Also, I would want to point the mcs_map implemented in rtw_init_vht_cap().
>
> if (efuse->hw_cap.nss > 1) {
> highest = cpu_to_le16(780);
> mcs_map |= IEEE80211_VHT_MCS_SUPPORT_0_9 << 2;
> }
>
> This can only support up to 2SS, and I'm not sure if 'efuse->hw_cap.nss' is
> still sutiable for 8814AU.
>
rtw_init_vht_cap() will be fixed in the next patch set:
https://github.com/lwfinger/rtw88/blob/21a3fa7ec11a0cbb3be14145f45cdca35c3d3217/main.c#L1718
>>
>> With RA_INFO_HI the first C2H_RA_RPT comes at the normal time,
>> before the first CTRL-EVENT-SIGNAL-CHANGE:
>
> So, how about sending RA_INFO_HI unconditionally for 8814AU
> (just check chip ID as condition)?
>
I guess that's fine.
