[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.