On Mon, 2010-04-12 at 22:57 +0200, ext Kalle Valo wrote: > Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> writes: > > > There are triggers for reducing the timeout, other than those mentioned > > by you above. A hand-held might for example attempt to save power based > > on the amount of user activity on the device in general. > > Yes, this makes sense. We definitely want user space to inform kernel > about different requirements. > > > That's something only user space would know about, but still is a > > very important factor in deciding the dynamic ps timeout value. > > But we do not want to tie our hands to a simple timeout value because > that only applies to the very crude dynamic ps implementation we have > currently. What if, next year, we have an uber cool new power save > implementation in mac80211 which doesn't use the timeout value at all, > what do we do with the nl80211 timeout parameter then? Deprecate it? > > Also please remember we have also other cfg80211 drivers than > mac80211. Finding a common ps interface for all of them is next to > impossible. Some of them might support ps timeout, but some of them > will not. > > > Also AFAIK currently in nl80211 there is no way go to "full power-save" > > i.e. disable dynamic power-save, which is something user-space might > > want to do to conserve power if the hand-held is not being used. > > With a more advanced power save implementation in mac80211 we should > be able to this automatically, for example, based on information from > PM qos interface, amount of data transfered etc. > > > Are you more hesitant on the concept of configuring the dynamic ps > > behavior from user-space or the granularity of control here? > > For me it's the former. > > > In the nl80211 interface the literal timeout value could be replaced > > by something to indicate the level of power-saving needed, for > > example. > > Something like levels 1-5? This was proposed some time (years?) ago, I > didn't like it then and I didn't like it now. It's just too vague. > > I think power save control should happen outside nl80211. The problem > here is that we want to inform kernel about events (or states) in user > space (display turned off, user activity, voip call etc.). We need a > different interface for that, nl80211 is not suitable for this. Also > other subsystems than wireless would definitely benefit from this kind > of information. The interface might already exist (pm qos?) or we have > to create a new one, I haven't studied this that much. > > >> In some sense I think it would be smarter to implement a gradual > >> powersave policy where the device first still wakes up for every > >> beacon and only later goes down to waking up for DTIM only (which > >> may or may not be the same ...) > > > > Yes, this is a good idea, although I still feel it does not alleviate > > the need for what I tried to explain above. > > The need is definitely valid, I don't deny that. It just needs to be > implemented differently compared to what old Wireless Extensions did. > > I would recommend to see if the pm qos interface can be used to hint > mac80211 dynamic ps enough so that you would get similar end result as > with the WE power timeout value. It should be possible, but I haven't > checked the code myself. > Okay, agreed. I will get back to the drawing board with this. -Juuso -- 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
