[ath9k-devel] [question] TBTT value

From: Janusz Dziedzic <janusz.dziedzic@tieto.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [question] TBTT value
Date: Mon, 28 Nov 2016 07:50:33 +0100	[thread overview]
Message-ID: <CALhHN=o33k_U7=cE49cb0tjP1ALSqk=tjP4SZanOV_0ixp3Xuw@mail.gmail.com> (raw)
In-Reply-To: <CANfLQrY8TDkoqCqRyyGhyURjLFoBN3HLEaijxAqbKsYriMt_bA@mail.gmail.com>

On 26 November 2016 at 14:18, Gucea Doru <gucea.doru@gmail.com> wrote:
> On Tue, Nov 22, 2016 at 9:16 AM, Janusz Dziedzic
> <janusz.dziedzic@tieto.com> wrote:
>> On 21 November 2016 at 18:06, Gucea Doru <gucea.doru@gmail.com> 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.
>
> From my tests with the ath9k_htc driver I noticed a buggy PS
> behaviour. The biggest problem seems to be that the
> ath9k_hw_set_sta_beacon_timers function is never called, so once the
> hardware enters the PS mode there is no hardware trigger to wake up
> the hardware. However, there is a mac80211 beacon loss software timer
> is the one that wakes up the hardware after 7 lost beacon.
>
ath9k have to receive all beacons - check PVB/Multicast - while don't
use firmware ...

In case of ath9k_htc probably firmware can do that and send beacon
only in case PVB/Multicast changed - no need to wakeup mac80211 each
beacon - but I think you can check this while firmware source are
available ...

BTW, as I remember mac80211 PS is buggy and because of that is
disabled by default in ath9k*

BR
Janusz

> Could you provide me more details about the link between Power Save
> Mode and the hardware triggers/sleep registers from
> ath9k_hw_set_sta_beacon_timers?
> The ath9k_hw_set_sta_beacon_timers should be called every time a
> beacon is received, right?
>
> [1] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.3#L2269
> [2] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/main.c#L486
> [3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c?v=2.6.35#L639
>
>
>> BR
>> Janusz
>>
>>> Thanks,
>>> Doru
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel