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