On 26 November 2016 at 14:18, Gucea Doru <gucea.d...@gmail.com> wrote: > On Tue, Nov 22, 2016 at 9:16 AM, Janusz Dziedzic > <janusz.dzied...@tieto.com> wrote: >> On 21 November 2016 at 18:06, Gucea Doru <gucea.d...@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@lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
