RE: [PATCH v11 5/7] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS

luka.gejak@linux.dev [off-list ref] wrote:

From: Luka Gejak <redacted>

The RTL8723BS reports free TX page counts that the generic 8051 path
reads back from the chip on every transfer, which is both slow over SDIO
and unreliable on this part: the register frequently reads back zero
while pages are in fact available. It also gates transmission on a free
count in the SDIO output queue, REG_SDIO_OQT_FREE_PG, which rtw88 does
not track at all. The vendor driver calls this the OQT free space and
never expands the acronym; the register holds the number of further
transfers the SDIO output queue can accept, and the chip discards
writes that arrive when it has run out.

Mirror the vendor driver and keep the per-queue and public page counts
in software, seeded at start and resynchronised from the chip only when
the cached counts say there is not enough room. Wait for a free output
queue entry before writing, and account for the pages consumed after a
successful transfer.

rtw_sdio_write_port() becomes a dispatcher. It works out the transfer
address and the aligned transfer size, which both paths need, and hands
them to rtw_sdio_write_port_8723bs() or rtw_sdio_write_port_generic().
The transfer itself moves into rtw_sdio_write_to_port(), which both
call, so the generic path is step for step what it was. The padding
added by the previous patch stays in rtw_sdio_write_port(), so it still
runs once for both paths and stays outside the credit mutex.

The RTL8723BS path keeps a separate length for the accounting. The chip
charges pages by the frame length rather than by the padded transfer, as
the vendor driver does, and the two differ just above a block boundary:
a 1025 byte frame is nine pages by length and twelve by the padded size.

The check, the output queue wait and the accounting are serialised by
a mutex. The TX worker and the H2C path reach this function
concurrently, and two writers that both pass the checks can otherwise
claim the same pages and output queue entry, after which the chip
silently discards whichever transfer arrives second. The vendor driver
avoids the same race by funnelling all transmission through one thread.

Measured on RTL8723BS hardware against an iperf3 server one hop behind
the AP, with the wlan0 byte counters as ground truth. On the generic
path the association completes but no data passes at all: TCP and UDP
both measure 0 bit/s in either direction. With this patch TCP is
25.3 Mbit/s up and 37.3 Mbit/s down, and UDP is 25.0 Mbit/s up at 0%
loss.

Signed-off-by: Luka Gejak <redacted>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>