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

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

Mehmet Fide <mehmet.fide@gmail.com> wrote:
> Hi Ping-Ke,
> 
> On 2026-10-19, Ping-Ke Shih wrote:
> > It'd be better to see every count stays on the air. Will you implement
> > to handle TBTT events? Can you share a draft first or a separate patch
> > (e.g. patch 3/3 to improve missing count)?
> 
> The USB chips raise no TBTT interrupt, so the countdown work reads the
> TSF and queues itself for 10 ms after the next TBTT. That gives a
> download about 80 ms to run late before a beacon goes out without it;
> one later than that is still followed by its successor at once, as in
> v6. A TSF that moved by more than a beacon interval, an IBSS merge or
> a reset, restarts the schedule from the TBTT ahead.
> 
> On the 8821CU the downloads land 13 to 22 ms after the TBTT; with a
> 60 ms delay on every second download the sniffer saw 9, 8, 7, 6, 5,
> 4, 3, 2, 1 for count 10, with 95 ms it saw 9, 8, 8, 6, 6, 4, 4, 2, 2,
> and the AP switched at the same time in all cases.

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 idea, on top of 2/2:
> 
>         /* csa_start: the first download goes with the TBTT ahead */
>         tsf = read_tsf(rtwvif->port);     /* 64 bit, 0x560 for port 0 */
>         csa_tbtt = tsf - tsf % beacon_int;

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

>         csa_queue();
> 
>         /* csa_queue, after every download */
>         csa_tbtt += beacon_int;           /* the TBTT this download is for */
>         delay = csa_tbtt + 10ms - read_tsf();
>         if (delay > beacon_int + 10ms || delay < -beacon_int)
>                 /* the TSF moved (IBSS merge, reset): start over */
>                 csa_tbtt = next TBTT after now, delay = csa_tbtt + 10ms - now;
>         queue_delayed_work(csa_beacon_work, max(delay, 0));
> 
> So a download on time runs 10 ms after its TBTT;

Can you measure this on USB 2.0 port with some traffic?
My concern is that low speed port with traffic results in missing countdown.
But it might be equal or better than v6, not worse.

> one late by less
> than ~80 ms still makes the next beacon; one later than that gets a
> delay of zero for its successor, the catch-up of v6. Nothing else
> changes, the download and ieee80211_csa_finish() stay as they are.
> 
> One thing I do not have: the TSF registers of the ports other than 0,
> for an AP that comes up next to a station interface. rtw88 only names
> REG_USTIME_TSF; is it 0x568 for port 1, and where are ports 2 to 4?

See rtw_hal_get_tsftr_by_port() [1]

[1] https://github.com/kimocoder/88x2cu/blob/main/hal/hal_com.c#L13181

> If this is the way you want it, it becomes patch 3/3 of v7 with 1/2
> and 2/2 unchanged.

It is nice to me that the sniffer saw perfect countdown. Do you have
any concern about reading TSF as parameters of CAS work delay?

Ping-Ke