On Wed, Feb 13, 2013 at 10:43:14PM +0100, Arend van Spriel wrote: > On 02/13/2013 08:25 PM, Seth Forshee wrote: > > On Wed, Feb 13, 2013 at 07:54:19PM +0100, Arend van Spriel wrote: > >> On 02/13/2013 06:04 PM, Seth Forshee wrote: > >>>> Is all this really worth it? It seems a quick fix for brcmsmac might be > >>>>> to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is > >>>>> enabled in the config, and then go implement a real solution like I > >>>>> described earlier with powersave being separated out of the core > >>>>> mac80211 routines, and actually made possible for multiple interfaces? > >>> Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable > >>> PS is sent the flag won't be set, as we're still on the operating > >>> channel. When we're actually off-channel the value of PM doesn't matter > >>> for the types of frames which are being sent. The only quick fix I've > >>> found is to watch out for frames with PM set and set the powersave bit > >>> while they're being transmitted. > >> > >> I actually don't see that one fly. The frames are posted on a DMA fifo > >> towards the hardware so in the driver we have no clue when that frame is > >> being processes/transmitted hence no way of knowing when to write the > >> register(s). > > > > There's a couple of ways of doing it. I had a working patch at one point > > but can't seem to find it now, so I'm not sure which way I used. You're > > right though that we can't tell when the hardware is actually processing > > or transmitting the frame, so in either case MCTL_HPS has to be set > > before you put the frame in the tx fifo. > > > > The first option is that for any frame with PM set, set MCTL_HPS when > > mac80211 hands off the frame and clear it once it has finished > > transmitting. > > > > The second option is to look specifically for nullfunc frames and set or > > clear MCTL_HPS based on the value of PM. > > > > Either of these should work fine with the current mac80211 code, but > > overall the second one is probably a little safer. > > So you have verified that the last packet mac80211 sends before going > off-channel is the nullfunc frame with PM bit set. I have seen packets > coming in our driver during the .flush() callback, but never checked > whether the last of those packets is indeed the nullfunc. The other set of patches I was working on ensures that the last frame before going off-channel is a nullfunc with PM set. The order of events is now: * stop the mac80211 queues with the offchannel stop reason * flush * send a nullfunc with PM set * flush again Without the first flush ath9k was often transmitting data frames with PM clear after the nullfunc. The second flush ensures the nullfunc gets sent before we go off-channel. Since the mac80211 queues are stopped during the flushes you shouldn't see any frames coming in (at least not during these flushes). I've done numerous wireshark traces with both brcmsmac and ath9k with these changes, and the nullfunc is the last thing on the air before going off-channel. Of course things still aren't working quite right with brcmsmac since the hardware is clearing the PM bit. Seth -- 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
