On Thu, 2013-01-31 at 16:23 +0100, Marco Porsch wrote: > On 01/31/2013 02:51 PM, Johannes Berg wrote: > > On Wed, 2013-01-23 at 11:19 +0100, Marco Porsch wrote: > > > >> Expose a callback ieee80211_mps_init for drivers to register > >> mesh powersave ops: > >> - hw_doze - put the radio to sleep now > >> - hw_wakeup - wake the radio up for frame RX > >> These ops may be extended in the future to allow drivers/HW to > >> implement mesh PS themselves. (The current design goal was to > >> concentrate mesh PS routines in mac80211 to keep driver > >> modifications minimal. > >> > >> Track the beacon timing information of peers we are in PS mode > >> towards. Set a per-STA hrtimer which will trigger a wakeup right > >> before the peer's next TBTT. > >> Also use the same hrtimer to go to sleep mode after not > >> receiving a beacon in a defined time margin. In this case > >> calculate the next TBTT and increase the margin. > >> > >> For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start > >> a timer which triggers a hw_doze call on expiry. > > > > Hmm. I'm not completely happy with this hrtimer stuff in mac80211. > > There's a lot of (USB) hardware that could never implement such a thing, > > but could, conceivably, implement this differently? > > The use of hrtimers for MPS is debatable currently. The approach of > calculating the peer's TSF should be accurate to the usec. Good timing > here directly affects the energy savings. On the other handside the > margin of 5ms used shows that something is not working as expected yet. > If this cannot be fixed, I may as well use regular timers here. How > strongly do you oppose hrtimers? :) Oh it's not the user of hrtimers vs. timers (although first using an hrtimer and then kicking off to a work struct seems ... pointless and questionable), it's more the fact that you're starting to put real-time behaviour into mac80211. I'm not entirely convinced that is the right approach for "core" mac80211. > > So I think you should (at least attempt to) make an implementation that > > is less tied to the exact timing implementation. Maybe program the > > wakeup TBTT in advance. Maybe with a small library the driver can > > connect to this that uses hrtimers to implement it? That could then also > > assume that callbacks need not sleep, thus allowing to reduce > > TBTT_MARGIN. > > > > In theory I think with ath9k you could even use hardware timers & > > interrupts to wake the hardware, thus probably being able to reduce > > TBTT_MARGIN significantly. > > Earlier, I had successfully implemented wakeups using ath9k HW before we > at cozybit decided to concentrate all code in mac80211. Concerning ath9k > it worked fine but required more callbacks to mac80211 and will > eventually add redundant code that has to be maintained to multiple drivers. The question isn't so much about concentrating the code, I think you can still do that for most devices, and use hrtimers more effectively, if you somewhat put it off to the side in a less integrated way. I'm thinking that, for example, if I ever wanted to implement this with our current device (not likely, but just for perspective) we'd definitely want to program the firmware to do all the real-time behaviour. In fact, I suspect we probably could with the new MVM firmware API. Therefore, I think it would be better to have a more generic time-oriented interface in mac80211, and put the actual implementation of the events a bit separately in a way that it is optional for drivers and not used in the API. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
