[ath9k-devel] [question] TBTT value

Discussion:

Gucea Doru

2016-11-21 17:06:19 UTC

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

Janusz Dziedzic

2016-11-22 07:16:00 UTC

Permalink

Post by 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 -
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

Post by Gucea Doru
Thanks,
Doru
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Gucea Doru

2016-11-26 13:18:52 UTC

Permalink

On Tue, Nov 22, 2016 at 9:16 AM, Janusz Dziedzic

Post by Janusz Dziedzic

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.

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

Post by Janusz Dziedzic
BR
Janusz

Post by Gucea Doru
Thanks,
Doru
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Janusz Dziedzic

2016-11-28 06:50:33 UTC

Permalink

Post by Gucea Doru
On Tue, Nov 22, 2016 at 9:16 AM, Janusz Dziedzic

Post by Janusz Dziedzic

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

Post by Gucea Doru
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

Post by Janusz Dziedzic
BR
Janusz

Post by Gucea Doru
Thanks,
Doru
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel