Re: [PATCH rtw-next 0/5] wifi: rtw88: pci: Support an older design, like RTL8821AE/RTL8812AE

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 29/10/2026 02:51, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 27/10/2026 03:52, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> This series extends rtw88_pci to support an older design, like
>>>> RTL8821AE, RTL8812AE, RTL8723BE, etc.
>>>
>>> The older design is own-bit ring, and the new is read/write index ring
>>> with buffer descriptor. Can we use 'own-bit' instead of 'old' as the file
>>> name ?
>>>
>>
>> Sure, the file name is not a problem. What about the code? All the functions
>> in pci_old.c are prefixed with "rtw_pci_old", and there is rtw_pci_gen_old
>> and rtw_pci_gen_new. Should I rename all of these?
> 
> I'd prefer having consistent suffix as file name, but I have no good idea
> for the suffix. Maybe, '_ob' means 'own-bit ring'?
> 

That works for me.

Maybe I will leave the renaming for the last version of the patches,
to avoid mixing it with the other changes.

>>>> rtw88 is not without problems, but in my experience it's more reliable
>>>> with these two chips. In the 6-8 months I used this code, I observed
>>>> these problems with rtw88:
>>>>
>>>>  * The top speed is a bit lower: ~220 Mbps instead of ~300 Mbps. In the
>>>>    case of TX, the difference is due to the EDCA parameters. rtw88 uses
>>>>    the ones from mac80211 (rtw_conf_tx()), whereas rtlwifi uses its own
>>>>    "turbo" values when there are not too many non-BE packets
>>>>    (rtl8821ae_dm_check_edca_turbo()). Not sure why the RX speed is
>>>>    lower.
>>>
>>> Maybe you can try to compare them by VO or VI packets?
>>>
>>
>> Do you mean for the TX speed comparison?
> 
> Yes.
> 

I just used the turbo value 0x5ea42b from rtlwifi. With that the rtw88 TX
speed matches rtlwifi.

>>>>
>>>>    It uses RX descriptor number 511, then number 0, then it doesn't
>>>>    want to use number 1 for "a while". It raises IMR_RDU once or twice,
>>>>    and only then it moves on to number 1, 2...
>>>>
>>>>    Usually when it raises IMR_RDU there are 510 or 511 RX descriptors
>>>>    available (out of 512), so it has no excuse.
>>>>
>>>>    Once it has raised IMR_RDU the RX speed doesn't exceed 70-100 Mbps
>>>>    anymore.
>>>
>>> If driver can receive packets on time, how does it raise ISR_RDU?
>>
>> It's a mystery for me.
>>
>>> Is RX interrupt triggered on time?
>>>
>>
>> I'm not sure how to check this. I assume it is triggered on time because
>> the ring was always nearly empty when it raised IMR_RDU.
> 
> If interrupt handler can handle (ignore) "empty" RX ring , it might be harmless
> to see raised IMR_RDU, right?

It is harmless in the sense that everything keeps working, just the RX
speed is low.