[ath9k-devel] [question] TBTT value

[ath9k-devel] [question] TBTT value

[Gucea Doru]

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

Thanks,
Doru

[ath9k-devel] [question] TBTT value

[Janusz Dziedzic]

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.

BR
Janusz

> Thanks,
> Doru
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [question] TBTT value

[Gucea Doru]

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.

[ath9k-devel] [question] TBTT value

[Janusz Dziedzic]

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