Arve,
What ever happened with your series on the Android PM extensions you
had submitted in 2009 [1] ? I'm working on ath6kl right now and I'm
going to remove all that early suspend crap as its not upstream and I
want to get ath6kl into upstream proper. Do you have plans for a
replacement? Since the thread covers wake locks, have you ironed out
what you are going to do with that as well?
[1] https://lists.linux-foundation.org/pipermail/linux-pm/2009-February/019498.html
Luis
On Wed, Mar 23, 2011 at 01:05:47PM -0700, Luis R. Rodriguez wrote:
> Arve,
>
> What ever happened with your series on the Android PM extensions you
> had submitted in 2009 [1] ? I'm working on ath6kl right now and I'm
> going to remove all that early suspend crap as its not upstream and I
> want to get ath6kl into upstream proper. Do you have plans for a
> replacement? Since the thread covers wake locks, have you ironed out
> what you are going to do with that as well?
Wake locks are all taken care of, see:
http://lwn.net/Articles/416690/
for the details.
thanks,
greg k-h
2011/3/23 Luis R. Rodriguez <[email protected]>:
> Arve,
>
> What ever happened with your series on the Android PM extensions you
> had submitted in 2009 [1] ? I'm working on ath6kl right now and I'm
> going to remove all that early suspend crap as its not upstream and I
> want to get ath6kl into upstream proper. Do you have plans for a
> replacement?
There is no planned replacement for early suspend, and it will
probably be dropped form the android kernel at some point. The wifi
driver use it to enter a lower operating state when the screen is off.
If you driver does have any other way to put the driver in this state
you need to add an interface that lets user-space select that state
directly.
> Since the thread covers wake locks, have you ironed out
> what you are going to do with that as well?
>
The wakelock code did not get merged. Instead there is a new interface
that should provide the same functionality to drivers, but this has
not integrated with android yet (and you cannot use it directly as it
does not provide the same user-space interface). In theory, you should
be able to replace all the wakelocks in your driver with calls to the
mainline api. Even if you cannot test the result this is better than
just deleting the wakelocks.
--
Arve Hj?nnev?g
On Wed, 2011-03-23 at 17:47 -0700, Arve Hjønnevåg wrote:
> There is no planned replacement for early suspend, and it will
> probably be dropped form the android kernel at some point. The wifi
> driver use it to enter a lower operating state when the screen is off.
> If you driver does have any other way to put the driver in this state
> you need to add an interface that lets user-space select that state
> directly.
The interface is called "ip link set wlan0 down".
johannes
On Thu, 2011-03-24 at 10:04 +0100, Johannes Berg wrote:
> On Wed, 2011-03-23 at 17:47 -0700, Arve Hjønnevåg wrote:
>
> > There is no planned replacement for early suspend, and it will
> > probably be dropped form the android kernel at some point. The wifi
> > driver use it to enter a lower operating state when the screen is off.
> > If you driver does have any other way to put the driver in this state
> > you need to add an interface that lets user-space select that state
> > directly.
>
> The interface is called "ip link set wlan0 down".
Or, in fact, just powersaving mode. But I don't think for a wifi driver
there's any need for special driver specific states.
johannes
Johannes Berg <[email protected]> writes:
> On Thu, 2011-03-24 at 10:04 +0100, Johannes Berg wrote:
>> On Wed, 2011-03-23 at 17:47 -0700, Arve Hjønnevåg wrote:
>>
>> > There is no planned replacement for early suspend, and it will
>> > probably be dropped form the android kernel at some point. The wifi
>> > driver use it to enter a lower operating state when the screen is off.
>> > If you driver does have any other way to put the driver in this state
>> > you need to add an interface that lets user-space select that state
>> > directly.
>>
>> The interface is called "ip link set wlan0 down".
>
> Or, in fact, just powersaving mode.
Exactly.
> But I don't think for a wifi driver there's any need for special
> driver specific states.
In maemo, to save power, we decreased the dynamic power save timeout
whenever display was turned off. This was all done from user space and
wifi driver in the kernel was completely unaware of the display state.
But I think this is still a hack and we should save as much as
possible power in all cases, despite the display state. Instead power
save parameters should automatically change based on the transfer
characteristics.
Few examples what I mean:
o if idle or very little traffic -> more aggressive power save
o if latency critical packets (dns requests, higher qos classes etc)
-> decrease latency
o if active data transfer -> increase throughput
And before someone suggests adding dynamic timeout variable to
nl80211: I think it's very much implementation specific parameter. Not
all drivers support it and it might be that even in future mac80211
uses something else. So having the timeout variable in nl80211 is not
a long term solution.
--
Kalle Valo
Kalle Valo <[email protected]> writes:
> In maemo, to save power, we decreased the dynamic power save timeout
> whenever display was turned off. This was all done from user space and
> wifi driver in the kernel was completely unaware of the display state.
[...]
> And before someone suggests adding dynamic timeout variable to
> nl80211: I think it's very much implementation specific parameter. Not
> all drivers support it and it might be that even in future mac80211
> uses something else. So having the timeout variable in nl80211 is not
> a long term solution.
I totally forgot that Juuso added QoS requirements support to
mac80211. And that's the proper wayq to do this, user space sets QoS
requirements based on display state, and whatever else it thinks is
important, and mac80211 adapts the power save parameters accordingly.
In this method we are not revealing any implemention details to user
space, and that's always a good thing.
--
Kalle Valo