From: Marco Porsch <marco@cozybit.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling
Date: Mon, 11 Feb 2013 13:03:49 +0100 [thread overview]
Message-ID: <5118DE25.9090908@cozybit.com> (raw)
In-Reply-To: <1360360665.29851.37.camel@jlt4.sipsolutions.net>
On 02/08/2013 10:57 PM, Johannes Berg wrote:
> On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote:
>
>>>> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
>>>> a timer which triggers a doze call on expiry.
>>>
>>> That seems questionable -- drivers are not required to request each
>>> beacon. I know you only want to make it work on ath9k, but I don't think
>>> "stretching" the API, without even documenting it, is a good idea.
>>
>> Currently, we already use ieee80211_beacon_get_tim as time reference for
>> mesh sync's adjust_tbtt. And, as far as I know, all mesh-capable drivers
>> use the call for each and every beacon.
>
> Oops, why did I miss that before? :-)
>
>> So what would you recommend: keep using beacon_get and adding
>> documentation - or - creating an exported callback for awake_window_start?
>
> I guess you could add it... However, I don't really fully understand.
> There's no guarantee that fetching the beacon is done anywhere close to
> TBTT? Or does ath9k happen to do it just after TXing a beacon? You're
> encoding quite a lot of ath9k-specific assumptions here it seems?
I think the assumption is currently correct for ath5k, ath9k, ath9k_htc,
carl9170 and rt2800 (that's as far as I checked). All of these fetch a
beacon on SWBA/PRETBTT interrupt (more or less) immediately before TBTT.
--Marco
WARNING: multiple messages have this Message-ID (diff)
From: Marco Porsch <marco@cozybit.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: mcgrof@qca.qualcomm.com, jouni@qca.qualcomm.com,
vthiagar@qca.qualcomm.com, senthilb@qca.qualcomm.com,
linux-wireless@vger.kernel.org, devel@lists.open80211s.org,
ath9k-devel@lists.ath9k.org
Subject: Re: [RFCv2 2/3] mac80211: mesh power save doze scheduling
Date: Mon, 11 Feb 2013 13:03:49 +0100 [thread overview]
Message-ID: <5118DE25.9090908@cozybit.com> (raw)
In-Reply-To: <1360360665.29851.37.camel@jlt4.sipsolutions.net>
On 02/08/2013 10:57 PM, Johannes Berg wrote:
> On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote:
>
>>>> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start
>>>> a timer which triggers a doze call on expiry.
>>>
>>> That seems questionable -- drivers are not required to request each
>>> beacon. I know you only want to make it work on ath9k, but I don't think
>>> "stretching" the API, without even documenting it, is a good idea.
>>
>> Currently, we already use ieee80211_beacon_get_tim as time reference for
>> mesh sync's adjust_tbtt. And, as far as I know, all mesh-capable drivers
>> use the call for each and every beacon.
>
> Oops, why did I miss that before? :-)
>
>> So what would you recommend: keep using beacon_get and adding
>> documentation - or - creating an exported callback for awake_window_start?
>
> I guess you could add it... However, I don't really fully understand.
> There's no guarantee that fetching the beacon is done anywhere close to
> TBTT? Or does ath9k happen to do it just after TXing a beacon? You're
> encoding quite a lot of ath9k-specific assumptions here it seems?
I think the assumption is currently correct for ath5k, ath9k, ath9k_htc,
carl9170 and rt2800 (that's as far as I checked). All of these fetch a
beacon on SWBA/PRETBTT interrupt (more or less) immediately before TBTT.
--Marco
next prev parent reply other threads:[~2013-02-11 12:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 11:48 [ath9k-devel] [RFCv2 0/3] mesh power save - hardware doze Marco Porsch
2013-02-06 11:48 ` Marco Porsch
2013-02-06 11:48 ` [ath9k-devel] [RFCv2 1/3] mac80211: move mesh sync beacon handler into neighbour_update Marco Porsch
2013-02-06 11:48 ` Marco Porsch
2013-02-06 11:48 ` [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling Marco Porsch
2013-02-06 11:48 ` Marco Porsch
2013-02-08 9:20 ` [ath9k-devel] " Johannes Berg
2013-02-08 9:20 ` Johannes Berg
2013-02-08 10:09 ` [ath9k-devel] " Marco Porsch
2013-02-08 10:09 ` Marco Porsch
2013-02-08 21:57 ` [ath9k-devel] " Johannes Berg
2013-02-08 21:57 ` Johannes Berg
2013-02-11 12:03 ` Marco Porsch [this message]
2013-02-11 12:03 ` Marco Porsch
2013-02-13 14:59 ` [ath9k-devel] " Johannes Berg
2013-02-13 14:59 ` Johannes Berg
2013-02-06 11:48 ` [ath9k-devel] [RFCv2 3/3] ath9k: mesh powersave support Marco Porsch
2013-02-06 11:48 ` Marco Porsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5118DE25.9090908@cozybit.com \
--to=marco@cozybit.com \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.