Re: [PATCH rtw-next v6 2/2] wifi: rtw88: support channel switch in AP mode

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi Ping-Ke,

On 2026-10-20, Ping-Ke Shih wrote:
> Do the 60 / 95 ms delay here to substitute 10ms of
> " delay = csa_tbtt + 10ms - read_tsf();" below?
>
> I think 10ms is reasonable. Not sure what is the purpose of 60/95ms ?

The margin stays 10 ms. The 60 and 95 ms were a test build that sleeps
before every second download: with 60 ms every count still went out,
with 95 ms the late count stayed out and the next one followed at once.

> Use proper functions to do 64-bit arithmetic, like div_u64_rem().

The patch uses div_u64_rem(); the % was only for the sketch.

> Can you measure this on USB 2.0 port with some traffic?

All three ran at USB 2.0 high speed: an 8821CU and an 8822CU on an
i.MX8MP with PREEMPT_RT, an 8822BU on an AM62 without RT, all at
HZ=250. With iperf3 at 18 to 51 Mbps in either direction, the
downloads land 13 to 33 ms after the TBTT, never two in one beacon
period, and take about 3.3 ms with or without traffic. Every count the
sniffer saw matched the beacon timing.

> See rtw_hal_get_tsftr_by_port() [1]

Thanks. rtw88 needs no port selection: rtw_core_port_switch() moves an
AP to port 0 and an IBSS runs alone, so 0x560 shows the beaconing
interface; 0x557[6:4] reads 0 on all three chips. With a station
interface up first on the 8822CU, the AP moved to port 0 and every
count went out.

> Do you have any concern about reading TSF as parameters of CAS work
> delay?

One, found in the tests and handled in v7: when a TBTT falls between
the countdown template download and the first TSF read, that TBTT has
already sent the template, and one count went out twice. v7 takes a
TBTT within the margin before the start as the one that sent it; at
worst one count is left out and the timing holds. Forced both ways,
every run matched the beacon timing.

Otherwise none. The jiffy rounding adds at most 10 ms with HZ=100 and
8 ms with HZ=1000, well inside the ~80 ms a download may run late at
100 TU. A TSF jump restarts the schedule from the next TBTT. Below
about 30 TU a USB download may not fit in one interval; the catch-up
then keeps the timing at the cost of counts, as in v6.

I will send v7 with this as patch 3/3, patches 1 and 2 unchanged.

Regards,
Mehmet