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
On Sun, Jun 06, 2010 at 05:47:10PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
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 CPU, whereas
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
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
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
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 blocks are orthogonal to runtime PM.
--
James,
On Sun, 6 Jun 2010, James Bottomley wrote:
On Sun, 2010-06-06 at 17:46 +0200, Thomas Gleixner wrote:
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
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote:
Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.
Yep, the fastest way is to provide two stub inlines in pm.h and let
the driver flood come in.
As
On Sunday 06 June 2010, Matthew Garrett wrote:
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.
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
Well, we sort of tried this when Greg pulled some of them into the
staging tree. The problem is that without the annotations, the drivers
are still different, and patches won't apply, so, unsurprisingly, they
didn't get improved
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig h...@infradead.org wrote:
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
Well, we sort of tried this when Greg pulled some of them into the
staging tree. The problem is that without the annotations, the drivers
are still
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote:
I was shocked when Greg pulled the binder driver and some of the other
generic android drivers into staging, because it was always my
assumption that nobody upstream would want them. We did get some
bugfixes for the binder driver
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote:
Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.
Yep, the fastest way is to provide two stub inlines in
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem. I'd say it could have easily been done with the
manweeks
This doesn't even build, so I don't know how it was tested... Reverting the
offending commit (simple, but does require conflict resolution) at least lets
it compile, but I haven't tested whether it alone is enough to work in
practise yet... hoping Tomi might provide a real fix. Maybe even in
Brian,
On Sun, 6 Jun 2010, Brian Swetland wrote:
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem.
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 CPU, whereas the latter will be entered
whenever no suspend blocks are held.
Alan,
On Sun, 6 Jun 2010, Alan Stern 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 CPU, whereas the latter
49 matches
Mail list logo
