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

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

luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
> 
> 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 <luka.gejak@linux.dev>

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