[ath9k-devel] [question] TBTT value
Gucea Doru <[email protected]> Sat, 26 Nov 2016 15:18:52 +0200
| Newsgroups | org.ath9k.lists.ath9k-devel |
|---|---|
| Message-ID | <CANfLQrY8TDkoqCqRyyGhyURjLFoBN3HLEaijxAqbKsYriMt_bA@mail.gmail.com> |
On Tue, Nov 22, 2016 at 9:16 AM, Janusz Dziedzic <[email protected]> wrote: > On 21 November 2016 at 18:06, Gucea Doru <[email protected]> wrote: >> Hello, everyone >> >> We looked at the beacon behavior [1] at the station side and we are >> trying to understand the logic used for computing the nexttbtt - >> Target Beacon Transmission Time - value [2]: >> >> return (u32) tsf + divisor - offset; >> >> What's the reason for taking only 32 bits from TSF - which is 64 bits >> long - and losing the upper 32 bits? >> >> I noticed that the nexttbtt value is later used for arming the >> AR_NEXT_TBTT_TIMER [3] but there is no clear explanation related to >> this hardware timer. What is the connection between this hardware >> timer and TSF? My assumption is that, for triggering this timer, the >> value from the timer is continuously compared with the TSF value but I >> can't figure it out how a 32 bit value is compared with a 64 bit >> value. >> >> [1] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/common-beacon.c#L41 >> [2] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/common-beacon.c#L30 >> [3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.3#L2278 >> > > As I remember correctly this is used only in case chan_ctx is used > (driver loaded with use_chanctx=1 and compiled with > ATH9K_CHANNEL_CONTEXT). > This allow to create/use AP and STA on different channels (multichannel case). > We need to send (AP)/ recevie (STA) beacons and because of that we > need to configure timer and switch channels (reseting the chip). > So in common case we switch channels (from ath9k driver) about every 50ms. > > ath9k_hw_gen_timer_start() is used here (timer based on jiffies is not > good enough for that) and this required u32. > OK, so you are saying that the AR_NEXT_TBTT_TIMER might be used for supporting MCC. However, I'm not interested in understanding the MCC use-case, but the Power-Save one (I enabled it with iwconfig wlan0 set power_save on). The AR_NEXT_TBTT TIMER is set inside the ath9k_hw_set_sta_beacon_timers function [1] which also sets the sleep registers (AR_SLEEP1 and AR_SLEEP2). The role of the AR_NEXT_TBTT_TIMER is to wake up the hardware every time a new beacon is received. I'm not sure what should happen when the AR_NEXT_TBTT is triggered: 1) for ath9k: the interrupt routine, ath_isr [2], is called and the hardware enters the ATH9K_PM_AWAKE state, then the receive tasklet is scheduled. 2) for ath9k_htc: the receive callback, ath9k_htc_rxep [3], is called by the firmware, then the receive tasklet is scheduled, then the tasklet puts the hardware in the ATH9K_PM_AWAKE state.