Hi!
So for people who really care about running a mainline kernel on their
android device doing that part first on a generic ARM board in qemu
might be much better first step work.
On the other hand I've heard
that various hardware vendors or parties closed to them are rather
On Fri, 11 Jun 2010, Arve Hjønnevåg wrote:
Wait a second. Maybe I have misunderstood how timeouts are supposed to
work with wakelocks. I thought the idea was that the wakelock would be
released when the timeout expires or the event queue is emptied,
That is one way to use it, and I did
On Fri, Jun 11, 2010 at 04:48:15PM -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, Mark Brown wrote:
The clock framework is implemented independantly for each CPU.
That's not an impediment, since drivers' requirements regarding which
clocks remain running in which power states are
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
Do we at least have a clean way that a driver can
reject a system suspend? I've lost track of many
issues, but maybe this could be phrased as a QOS
constraint: the current config of driver X needs
clock Y active to enter the target
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
You've lost me. If the power manager is sitting inside a select/poll,
how can it miss the event (given that the event will make data
available to be read on one of the descriptors being polled)?
It cannot sit inside of select/poll all the
On Thu, 10 Jun 2010, David Brownell wrote:
This is a bit off the topic of Android
flamage, but I thought it would be worth
highlighting an example where the current
frameworks may still have a deficiency...
one that likewise relates to needing to
block entry ot a system suspend state, but
On Fri, 11 Jun 2010, James Bottomley wrote:
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
Do we at least have a clean way that a driver can
reject a system suspend? I've lost track of many
issues, but maybe this could be phrased as a QOS
constraint: the current config of
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, James Bottomley wrote:
The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific. Expressing them in a generic
way for the cpu govenors to make sense of
On Fri, 2010-06-11 at 10:46 -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, James Bottomley wrote:
On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
Do we at least have a clean way that a driver can
reject a system suspend? I've lost track of many
issues, but maybe this could
On Fri, 11 Jun 2010, Mark Brown wrote:
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, James Bottomley wrote:
The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific. Expressing them in a generic
On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, Mark Brown wrote:
On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
On Fri, 11 Jun 2010, James Bottomley wrote:
The one thing that does look difficult is that these power constraints
are device
2010/6/11 Alan Stern st...@rowland.harvard.edu:
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
You've lost me. If the power manager is sitting inside a select/poll,
how can it miss the event (given that the event will make data
available to be read on one of the descriptors being polled)?
--- On Fri, 6/11/10, James Bottomley james.bottom...@suse.de wrote:
Do we at least have a clean way that a driver can
reject a system suspend? I've lost track of
many
issues, but maybe this could be phrased as a QOS
constraint: the current config of driver X
needs
clock Y active
On Thursday, June 10, 2010, Neil Brown wrote:
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010,
On Thu, 10 Jun 2010 10:59:43 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, June 10, 2010, Neil Brown wrote:
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
So, for a phone-like system, where you'd generally want to simplify user
space,
having a power manager in the kernel seems to make sense to me.
I'm not clear where this requirement to simplify user space specifically
for
Hi!
We started here because it's possibly the only api level change we have --
almost everything else is driver or subarch type work or controversial but
entirely self-contained (like the binder, which I would be shocked to see
ever hit mainline). [...]
So why arent those bits
On Wed, 9 Jun 2010, Arve Hjønnevåg wrote:
I think this is where you misunderstood. There is no report wakeup
event as such. All that happens is that data becomes available to be
read from the input device file. However the power manager process
isn't polling the device file at this
On Wed, 9 Jun 2010 da...@lang.hm wrote:
why could the suspend blocker process see all events, but the power
manager process not see the events?
have the userspace talk to the power manager the way it does to the
suspend blocker now and what's the difference?
effectivly think s/suspend
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote:
Moreover, having thought a bit more about the power manager in user space
concept I'm not sure if it really is that better than the original wakelocks
idea. Namely, it only repaces a kernel-based mechanism with a user space
task doing basically
On Thursday, June 10, 2010, Alan Stern wrote:
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote:
Moreover, having thought a bit more about the power manager in user space
concept I'm not sure if it really is that better than the original wakelocks
idea. Namely, it only repaces a kernel-based
On Thursday, June 10, 2010, Mark Brown wrote:
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
So, for a phone-like system, where you'd generally want to simplify user
space,
having a power manager in the kernel seems to make sense to me.
I'm not clear where this
On Thursday, June 10, 2010, Neil Brown wrote:
On Thu, 10 Jun 2010 10:59:43 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, June 10, 2010, Neil Brown wrote:
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe
On Thu, Jun 10, 2010 at 05:46:46PM +0200, Rafael J. Wysocki wrote:
On Thursday, June 10, 2010, Mark Brown wrote:
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
So, for a phone-like system, where you'd generally want to simplify user
space,
having a power manager
2010/6/10 Alan Stern st...@rowland.harvard.edu:
On Wed, 9 Jun 2010, Arve Hjønnevåg wrote:
I think this is where you misunderstood. There is no report wakeup
event as such. All that happens is that data becomes available to be
read from the input device file. However the power manager
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
For that to work the wakeup events would have to be reported to the
power manager in a reliable way in the first place. Passing the file
descriptor that the app uses to the power manager does not work for
this, since the app could read the event
2010/6/10 Alan Stern st...@rowland.harvard.edu:
On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:
For that to work the wakeup events would have to be reported to the
power manager in a reliable way in the first place. Passing the file
descriptor that the app uses to the power manager does not
This is a bit off the topic of Android
flamage, but I thought it would be worth
highlighting an example where the current
frameworks may still have a deficiency...
one that likewise relates to needing to
block entry ot a system suspend state, but
in this case user-space isn't very involved
(just
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys you enough. In this case the question is
if the suspend
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
On the other hand I've heard
that various hardware vendors or parties closed to them are rather
annoyed by their drivers beeing stuck in the android
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
Wakeup event occurs, and the driver:
- report wakeup event type A
- queue event for delivery to user-space
That's not really two distinct steps. Queuing the event for delivery
to userspace involves waking up any tasks that are waiting to read
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the
2010/6/9 Alan Stern st...@rowland.harvard.edu:
On Tue, 8 Jun 2010, Arve Hjønnevåg wrote:
Wakeup event occurs, and the driver:
- report wakeup event type A
- queue event for delivery to user-space
That's not really two distinct steps. Queuing the event for delivery
to userspace
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power manager calls poll.
All
2010/6/9 da...@lang.hm:
On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote:
The power may not see the event, the process that reads the event will
always see it. If the power manager is not in the poll call when the
event happens, the process that reads the event can read the event
before the power
On Wed, 9 Jun 2010 21:51:38 -0700
Arve Hjønnevåg a...@android.com wrote:
The current user space interface does not require that clients
register the file descriptors that they get wakeup events from with
another process.
However I believe they *do* register these file descriptors with the
On Tuesday 08 June 2010, Arve Hjønnevåg wrote:
2010/6/6 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
...
If individual processes are frozen, we run into problems that we
cannot run into if we freeze and thaw all processes.
Not individual processes, but the
On Mon, 7 Jun 2010 20:05:56 -0700
Arve Hjønnevåg a...@android.com wrote:
Hi,
If you read an event that occurred after you blocked the task
freezing, then tasks will never get frozen again (until more events
occur). I think my original description was less confusing, but it
seems you got
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
The patch that modifies evdev (posted in this patchset) uses an ioctl
to enable the suspend blocker. Not all input devices are used for
wakeup events and those don't need to block suspend.
But you do have a 1-1 correspondence, right? That is, the
On Mon, 7 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
2010/6/8 Alan Stern st...@rowland.harvard.edu:
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
The patch that modifies evdev (posted in this patchset) uses an ioctl
to enable the suspend blocker. Not all input devices are used for
wakeup events and those don't need to block suspend.
But you do
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys you enough. In this case the question is
if the suspend blockers would extend the sleep time enough more to matter. As
per my other
On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote:
That takes a lot of the bullshit arguments about downstream users
being hurt out of the discussion. The above problems are way more
complex to resolve than the suspend blocker details.
That's another prove why we can let the
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side that didn't require
a kernel driver, had
On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig h...@infradead.org wrote:
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
The group ID stuff works incredibly well for gating device access --
we ensure that devices that need access from various processes end up
with perms like
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
Yes. Suspend
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get a
On Sun, 6 Jun 2010 19:21:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
~Vitaly
If you look at the suspend blocker
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side that didn't require
a kernel driver, had the same
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
And since Android can reach essentially the same low-power
state from idle as from suspend, it appears that they really don't need
any kernel changes at all.
Well, perhaps a hint to the scheduler to fall
--- On Mon, 6/7/10, Peter Zijlstra pet...@infradead.org wrote:
So what's up with this Binder stuff, from what I can see
its just
yet-another-CORBA. Why does it need a kernel part at all,
can't you
simply run with a user-space ORB instead?
I really don't get why people keep re-inventing
2010/6/5 Alan Stern st...@rowland.harvard.edu:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
Yes, we can keep all our user space suspend blockers and thaw the
frozen cgroup when any suspend blocker is held, but this would
eliminate any power advantage that freezing a cgroup has over using
2010/6/7 Peter Zijlstra pet...@infradead.org:
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side
2010/6/6 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might
On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij
linus.ml.wall...@gmail.com wrote:
So I would really like to know from the Android people why the
binder is in the kernel, after all. Could it *theoretically* be in
userspace, on top of some unix domain sockets, running as a
real-time scheduled
2010/6/6 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
Can you please explain in a consistent way how the application stack
and the underlying framework (which exists according to android docs)
is handling
2010/6/6 Alan Stern st...@rowland.harvard.edu:
On Sat, 5 Jun 2010, Alan Stern wrote:
If you are referring to the approach that we don't use suspend but
freeze a cgroup instead, this only solves the problem of bad apps. It
does not help pause timers in trusted user space code and in the
2010/6/6 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
Arve,
On Sun, Jun 6, 2010 at 7:43 AM, Matt Helsley matth...@us.ibm.com wrote:
On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
snip
events like input event go though a single thread in our system
process, while other events like network
On Sun, Jun 6, 2010 at 5:01 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 6 Jun 2010, Matthew Garrett wrote:
The difference between idle-based suspend and opportunistic suspend is
that the former will continue to wake up for timers and will never be
entered if something is using
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
In fact it's possible to do this with only minimal changes to the
userspace, providing you can specify all your possible hardware wakeup
sources. (On the Android this list probably isn't very large -- I
imagine it includes the keypad, the radio
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
Remember that suspend takes place in several phases, the first of which
is to freeze tasks. The phases can be controlled individually by the
process carrying out a suspend, and there's nothing to prevent you from
stopping after the freezer phase.
2010/6/7 Alan Stern st...@rowland.harvard.edu:
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
In fact it's possible to do this with only minimal changes to the
userspace, providing you can specify all your possible hardware wakeup
sources. (On the Android this list probably isn't very large --
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said:
So I would really like to know from the Android people why the
binder is in the kernel, after all. Could it *theoretically* be in
userspace, on top of some unix domain sockets, running as a
real-time scheduled daemon or whatever, still
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
It's true that under some exceptional circumstances the system would
never remove a wakeup source from the active list and then would
never go idle. But exactly the same problem exists with wakelocks, if
the kernel activates a wakelock and
2010/6/7 Alan Stern st...@rowland.harvard.edu:
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
It's true that under some exceptional circumstances the system would
never remove a wakeup source from the active list and then would
never go idle. But exactly the same problem exists with wakelocks,
2010/6/5 Arve Hjønnevåg a...@android.com:
On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven ar...@infradead.org wrote:
On Sat, 05 Jun 2010 11:54:13 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
Trusted processes are assumed to be
On Fri, 4 Jun 2010, Brian Swetland wrote:
Yeah, I do understand that we're not making it easy for ourselves
here. I think we hit the point where Rafael and Matthew signed off on
things and thought aha, linux-pm maintainers are happy, now we're
getting somewhere only to realize the light at the
On Thu, 3 Jun 2010, Arjan van de Ven wrote:
On Thu, 3 Jun 2010 19:26:50 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
If the system is idle (or almost idle) for long times, I would
heartily recommend actively shutting down unused cores. Some CPU's
are hopefully smart enough
On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/5 Arve Hjønnevåg a...@android.com:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a noticeable
On Thu, 3 Jun 2010, Linus Torvalds wrote:
On Thu, 3 Jun 2010, Linus Torvalds wrote:
so I'd like to see the opportunistc suspend thing think about CPU
offlining
Side note: one reason for me being somewhat interested in the CPU
offlining is that I think the Android kind of opportunistic
On Sun, Jun 6, 2010 at 10:20 AM, Brian Swetland swetl...@google.com wrote:
On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/5 Arve Hjønnevåg a...@android.com:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or
On Sun, Jun 6, 2010 at 1:32 AM, Vitaly Wool vitalyw...@gmail.com wrote:
It varies depending on device and usage. The battery monitoring on
NexusOne happens every ten minutes, so that's the longest you'll see a
N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes
between
On Sun, 6 Jun 2010, Brian Swetland wrote:
The savings in airplane mode (apart from preventing data connections,
which saves power by preventing data-hungry background apps from doing
much) is the difference between standby with radio (3-5mA) and without
(1-2mA). I'm not suggesting that
On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland swetl...@google.com wrote:
The common case for a phone is to be sitting around. Even for heavy
smartphone users, unless they power on, use the device screen-on for 4
hours solid or whatnot and drain the battery straight away, the device
is
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That is too simple. You also have to prevent A from being frozen while
it is processing the event or the result would be the same as if it
was frozen
On Sun, 6 Jun 2010, Vitaly Wool wrote:
On Sun, Jun 6, 2010 at 11:21 AM, Brian Swetland swetl...@google.com wrote:
In any case, I'm saying that suspending for minutes at a time
(typical, 10s of minutes or more in some cases, hours in others), does
happen and it does represent an improvement
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get a battery reading, store it and go back to
sleep, It does so every 10 seconds. But when it does so it only runs the one
process and then goes back to sleep.
system B has the same need, but
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's not an
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
Even worse, the suspend wakelock will keep the
whole kernel active, as opposed to powering off unused devices
separately as it's done in runtime PM.
That is not true. While the kernel is not suspended it does
runtime
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get a battery reading, store it and go back to
sleep, It does so every 10 seconds. But when it does so it only runs
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
Can you please explain in a consistent way how the application stack
and the underlying framework (which exists according to android docs)
is handling events and how the separation of trust level works
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler flor...@mickler.org wrote:
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
Even worse, the suspend wakelock will keep the
whole kernel active, as opposed to powering off unused devices
separately as it's done in
2010/6/6 Florian Mickler flor...@mickler.org:
Suspend_blockers allow the system to suspend (mem/sys/power/state
suspend), when the userspace decides that the device is not in use.
Sorry. What? Blockers allow the system to suspend?
So implementing suspend_blockers support does not impact any
On Sat, 5 Jun 2010, Alan Stern wrote:
If you are referring to the approach that we don't use suspend but
freeze a cgroup instead, this only solves the problem of bad apps. It
does not help pause timers in trusted user space code and in the
kernel, so it does not lower our average power
2010/6/6 da...@lang.hm:
On Sun, 6 Jun 2010, Brian Swetland wrote:
if you could shrink the time awake to 0.01 second per wakeup you would shift
this all up a category (and avoiding the need to wake everything up to
service a timer would help do this)
this effort very definantly has
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get a battery reading, store it and go back to
sleep, It does so every 10
2010/6/6 Arjan van de Ven ar...@infradead.org:
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hjønnevåg a...@android.com wrote:
the kernel has a set of infrastructure already to help here (range
timers, with which you can wakeup-limit untrusted userspace crap),
timer slack for legacy background
On Sun, 6 Jun 2010, Felipe Contreras wrote:
2010/6/6 Arjan van de Ven ar...@infradead.org:
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hj?nnev?g a...@android.com wrote:
the kernel has a set of infrastructure already to help here (range
timers, with which you can wakeup-limit untrusted userspace
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04,
On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote:
Sure, but my point was, some non-trivial (still kind of natural for a
smartphone) activities with the device will prevent it from suspending
for quite some time. Even worse, the suspend wakelock will keep the
whole kernel active, as
On Sun, Jun 06, 2010 at 12:05:57PM +0100, Alan Cox wrote:
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler flor...@mickler.org wrote:
That is not true. While the kernel is not suspended it does
runtime pm.
On several of our platforms runtime PM already includes suspend so a
suspend
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
Arve, we're still learning you have some more
On Sun, 2010-06-06 at 12:05 +0100, Alan Cox wrote:
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler flor...@mickler.org wrote:
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
Even worse, the suspend wakelock will keep the
whole kernel active, as opposed
On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
snip
events like input event go though a single thread in our system
process, while other events like network packets (which are also
wakeup events) goes directly to the app.
If you
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
On Sun, Jun 06, 2010 at 12:00:47PM +0200, Vitaly Wool wrote:
Sure, but my point was, some non-trivial (still kind of natural for a
smartphone) activities with the device will prevent it from suspending
for quite some time. Even worse, the suspend
On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Holding a suspend blocker is entirely orthogonal to runtime pm. The
whole kernel will not be active - it can continue to hit the same
low power state in the idle loop, and any runtime
On Sun, 6 Jun 2010, James Bottomley wrote:
3. We've lost sight of one of the original goals, which was to
bring the android tree close enough to the kernel so that the
android downstream driver and board producers don't have to
choose between the android kernel
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
On Sun, Jun 06, 2010 at 05:26:09PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Holding a suspend blocker is entirely orthogonal to runtime pm. The
whole kernel will not be active - it can continue to hit the same
low
1 - 100 of 191 matches
Mail list logo
