| Message ID | 20230816082133.57474-1-pkshih@realtek.com |
|---|---|
| Headers | show |
| Series | wifi: rtw89: preparation of TDMA-based MCC (STA+P2P) | expand |
Ping-Ke Shih <pkshih@realtek.com> writes: > TDMA-based MCC (STA+P2P) is a kind of multiple interfaces concurrence. > Basically, driver is to calculate timeslot pattern and firmware follows > the pattern to switch channels. Since BT-coexistence is also a TDMA-based > mechanism, also consider BT timeslot into pattern if BT devices present. What do you mean with TDMA here? It something like that in STA mode the driver enables 802.11 PS mode before going to another channel? Or something else?
On Wed, 2023-08-23 at 16:56 +0300, Kalle Valo wrote: > > Ping-Ke Shih <pkshih@realtek.com> writes: > > > TDMA-based MCC (STA+P2P) is a kind of multiple interfaces concurrence. > > Basically, driver is to calculate timeslot pattern and firmware follows > > the pattern to switch channels. Since BT-coexistence is also a TDMA-based > > mechanism, also consider BT timeslot into pattern if BT devices present. > > What do you mean with TDMA here? It something like that in STA mode the > driver enables 802.11 PS mode before going to another channel? Or > something else? > Yes, when it is working as STA mode or GC, using 802.11 PS mode before switching channel. When it plays as GO, NoA is used to inform GC absent timing. For example, STA on channel 1 + GO on channel 11, and preserve some time slot for BT (1) channel 1 (STA) +++++++++ (2) channel 11 (GO) +++++++++ BT ++++++++ |<----------------------->| Period (or cycle time) (1) issue null with power bit (2) issue beacon with NoA Though STA and GO are in different channels, they don't operate at the same time. This is the reason I point "TDMA" to prevent misunderstanding two virtual interfaces can operate two channels at the same time, which may be called DBS or DBCC. But, I'm trying to explain hardware capability correctly. Ping-Ke
Ping-Ke Shih <pkshih@realtek.com> writes: > On Wed, 2023-08-23 at 16:56 +0300, Kalle Valo wrote: >> >> Ping-Ke Shih <pkshih@realtek.com> writes: >> >> > TDMA-based MCC (STA+P2P) is a kind of multiple interfaces concurrence. >> > Basically, driver is to calculate timeslot pattern and firmware follows >> > the pattern to switch channels. Since BT-coexistence is also a TDMA-based >> > mechanism, also consider BT timeslot into pattern if BT devices present. >> >> What do you mean with TDMA here? It something like that in STA mode the >> driver enables 802.11 PS mode before going to another channel? Or >> something else? >> > > Yes, when it is working as STA mode or GC, using 802.11 PS mode before > switching channel. When it plays as GO, NoA is used to inform GC absent > timing. > > For example, STA on channel 1 + GO on channel 11, and preserve some > time slot for BT > > > (1) > channel 1 (STA) +++++++++ > > (2) > channel 11 (GO) +++++++++ > > BT ++++++++ > > |<----------------------->| > Period (or cycle time) > > (1) issue null with power bit > (2) issue beacon with NoA > > > Though STA and GO are in different channels, they don't operate at > the same time. This is the reason I point "TDMA" to prevent > misunderstanding two virtual interfaces can operate two channels > at the same time, which may be called DBS or DBCC. But, I'm trying > to explain hardware capability correctly. Got it, thanks for the great explanation. Just out of curiosity, how do you create your ascii diagrams? Is there some nifty tool to help with those? :)
On Wed, 2023-08-23 at 21:24 +0300, Kalle Valo wrote: > > > Just out of curiosity, how do you create your ascii diagrams? Is there > some nifty tool to help with those? :) > I draw these diagrams manually, not pretty but useful (I think so :) ). Recently, I draw a diagram in cover letter, because purpose of patchset is simple, but too much detail things cause patches complicated. So, I hope a diagram can help reviewers to have a concept quickly before reviewing my patches. Ping-Ke
Ping-Ke Shih <pkshih@realtek.com> writes: > On Wed, 2023-08-23 at 21:24 +0300, Kalle Valo wrote: >> >> >> Just out of curiosity, how do you create your ascii diagrams? Is there >> some nifty tool to help with those? :) >> > > I draw these diagrams manually, not pretty but useful (I think so :) ). > > Recently, I draw a diagram in cover letter, because purpose of > patchset is simple, but too much detail things cause patches > complicated. So, I hope a diagram can help reviewers to have a > concept quickly before reviewing my patches. At least I have found the diagrams very helpful :)
TDMA-based MCC (STA+P2P) is a kind of multiple interfaces concurrence. Basically, driver is to calculate timeslot pattern and firmware follows the pattern to switch channels. Since BT-coexistence is also a TDMA-based mechanism, also consider BT timeslot into pattern if BT devices present. To easier to review these 20+ patches, I summary basic purpose of these patches below by group, and submit them by small patchset one by one. Group 1. get BT timeslot from coex mechanism Group 2. adjust some stuff related to driver channel context Group 3. P2P NoA infrastructure to add the IE to beacon when playing GO Group 4. adjust driver to support 2 channel context Group 5. calculate timeslot patterns and trigger firmware to switch channels followed the patterns Group 6. disable some dynamic tracking mechanism of RF calibration when MCC is running. Group 7. monitor states and adjust timeslot patterns. For example, if BT device leaves, we can reassign the slot to WiFi. Group 8. Remain-on-channel and hardware scan are related to channel context, so need some treatments to work with MCC properly. Group 9. Finally, we declare 8852C to support MCC This patchset includes groups 1-4 above, and depends on another patch "wifi: rtw89: Introduce Time Averaged SAR (TAS) feature" because both modify the same file, not functional dependency. Zong-Zhe Yang (6): wifi: rtw89: add function prototype for coex request duration wifi: rtw89: refine rtw89_correct_cck_chan() by rtw89_hw_to_nl80211_band() wifi: rtw89: sar: let caller decide the center frequency to query wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vif wifi: rtw89: provide functions to configure NoA for beacon update wifi: rtw89: initialize multi-channel handling drivers/net/wireless/realtek/rtw89/chan.c | 124 ++++++++++++++++++ drivers/net/wireless/realtek/rtw89/chan.h | 5 + drivers/net/wireless/realtek/rtw89/coex.c | 3 +- drivers/net/wireless/realtek/rtw89/coex.h | 9 ++ drivers/net/wireless/realtek/rtw89/core.c | 114 +++++++++++----- drivers/net/wireless/realtek/rtw89/core.h | 78 +++++++++++ drivers/net/wireless/realtek/rtw89/debug.c | 10 +- drivers/net/wireless/realtek/rtw89/fw.c | 16 ++- drivers/net/wireless/realtek/rtw89/mac80211.c | 7 +- drivers/net/wireless/realtek/rtw89/phy.c | 29 ++-- drivers/net/wireless/realtek/rtw89/ps.c | 75 ++++++++++- drivers/net/wireless/realtek/rtw89/ps.h | 4 + drivers/net/wireless/realtek/rtw89/sar.c | 24 ++-- drivers/net/wireless/realtek/rtw89/sar.h | 6 +- 14 files changed, 436 insertions(+), 68 deletions(-)