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

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

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'?

> >> 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.

> >>
> >>    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?