Thanks, I've applied the x86 platform driver ones.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
continue to hit the same
low power state in the idle loop, and any runtime pm implementation in
the drivers will continue to be active.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
wakelock does interfere with existing power managemet at that
level (not to mention the maintenance mess it causes).
No, it doesn't. Android on omap will enter the mpu/core off state from
the idle loop even if a suspend block is held.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
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, 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, 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
doesn't let them
lose wakeup events in the process.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
At the point where you're rewriting the application you can just make it
adhere to our current behavioural standards anyway.
Thank you for confirming that the so
to the policy
manager as well. That's a moderate additional overhead.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
in recent kernels.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that are trusted to behave well are allowed to receive
wakeup events? Yes, that makes implementation significantly easier. If
that maps reasonably well onto the existing Android application space,
it may even be an acceptable compromise.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
and then actually initiate a suspend isn't an atomic
operation.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that everyone's happy, but it's not possible to do so by
fiat.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the
generic Android userspace) can be frozen, and you can use the scheduler
to make everything else Just Work. That's a rather big if, but you've
got a better idea of the state of the Android app base than I do.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
of situation then, as far as I can tell, you
need either suspend blockers or something so close to them that it makes
no difference.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Thu, May 27, 2010 at 04:28:51PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 15:06 +0100, Matthew Garrett wrote:
one way which indicates to the scheduler that tasks in TASK_RUNNING
should be scheduled, and when the session is idle we set the flag the
other way and all processes
lost.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
blockers. I've sent another mail expressing why I
don't think your proposed QoS style behaviour provides that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Thu, May 27, 2010 at 07:04:38PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Sure, if you're not using opportunistic suspend then I don't think
there's any real need for the userspace side of this. The question is
how to implement something with the useful
On Thu, May 27, 2010 at 07:13:11PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:07 +0100, Matthew Garrett wrote:
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally different to a deep idle state.
I think Alan and Thomas
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
You still need the in-kernel suspend blockers if you want to guarantee
that you can't lose wakeup events. But yes, if you're not concerned
handling badly behaved applications
?
How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
in a deep idle state either - its idle. We leave
the idle state to schedule anything.
Certainly, if you can force the system to be idle then you don't need
opportunistic suspend. But you haven't shown how to do that without it
being racey.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
idle. Since we can't rely
on the scheduler, we need drivers to know whether userspace has consumed
all wakeup events before allowing the transition to occur. Doing so
requires either in-kernel suspend blockers or something that's almost
identical.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:25 +0100, Matthew Garrett wrote:
How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?
Why would you care about the screen for a network event?
Because
sufficient.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:32 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:28:08PM +0200, Peter Zijlstra wrote:
Why would you care about the screen for a network event?
Because the application that needs to handle
pm_qos is an appropriate mechanism), but instead it may be something
like A key was pressed but never read or A network packet was
received but not delivered. These don't fit into the pm_qos model, but
it's state that you have to track.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
On Thu, May 27, 2010 at 07:46:37PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:41 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:35:50PM +0200, Peter Zijlstra wrote:
Then that's an application bug right there, isn't it?
If should have listened to the window server
or blocking
of applications then you don't lose wakeups. People keep conflating
separate issues.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
blockers.
That's entirely orthogonal to Android's runtime power management.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
If that's what you're aiming for then you don't need to block
applications on hardware access because they should all already have
idled themselves.
Correct
block and the
phone goes to sleep again.
I don't see how this behaviour can be emulated in your model.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, May 27, 2010 at 08:02:13PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
If you want to support forced suspend for laptops and you want to avoid
the risk of losing wakeups then you need in-kernel suspend blockers.
That's entirely orthogonal
On Thu, May 27, 2010 at 07:05:15PM +0100, Alan Cox wrote:
I'd prefer we avoided mixing them up. Everyone seems fairly happy with
the current operator ordered suspend behaviour I believe ?
No. The current mechanism can lose wakeup events.
--
Matthew Garrett | mj...@srcf.ucam.org
that? We can't rely on the process scheduler.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
If that's what you're aiming
On Thu, May 27, 2010 at 08:12:15PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
How long do you wait for applications to respond that they've stopped
drawing? What if the application is heavily in swap at the time?
Very realistic scenario on a mobile phone
the other.
Not at all. The entire point of opportunistic suspend is that I don't
care is currently in TASK_RUNNABLE or has a timer that's due to expire
in 100msec - based on policy (through not having any held suspend
blockers), I'll go to sleep. That's easily possible on PCs.
--
Matthew Garrett | mj
On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Actually, the reverse - there's no terribly good way to make PCs work
with scheduler-based suspend, but there's no reason why they wouldn't
work with the current opportunistic
On Thu, May 27, 2010 at 07:59:02PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
ACPI provides no guarantees about what level of hardware functionality
remains during S3. You don't have any useful ability to determine which
events will generate wakeups
On Thu, May 27, 2010 at 08:18:11PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 19:14 +0100, Matthew Garrett wrote:
If I get a WoL
packet in the 0.5 of a second between userspace deciding to suspend and
actually doing so, the system shouldn't suspend.
Please re-read Thomas
On Thu, May 27, 2010 at 08:22:08PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 19:17 +0100, Matthew Garrett wrote:
It's blocked on the screen being turned off. It's supposed to be reading
a network packet. How does it ever get to reading the network packet?
Its blocked because
is
actively interacting with the device, but in most cases processes
shouldn't be permitted to use any CPU when the session is idle. The
question is how to implement something that allows a CPU-guzzling
application to be idled without impairing its ability to process wakeup
events.
--
Matthew
suspend when you should have remained awake.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 27, 2010 at 08:53:33PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
But wakeup events won't be delivered to STOPped processes, and there's
Try the following
cat pipe
kill -STOP catpid
echo wombats
On Thu, May 27, 2010 at 10:23:50PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
A wakeup event is defined as one that wakes the system - if a system
can't be woken by a specific event then it's impossible to lose it,
since it wasn't a wakeup event to begin
On Thu, May 27, 2010 at 10:03:14PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
Ok. So the existing badly-behaved application ignores your request and
then gets blocked. And now it no longer responds to wakeup events. So
you
(). This is all existing solved stuff.
Isn't that the inverse of what we want? The application should default
to being SIGSTOPpable except in the case of it being in the process of
having a specific event delivered.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
standards anyway.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
How (and why) does the WoL (which may be *any* packet, not just a magic
one) turn the screen back on?
Well on my laptop today it works like
as force suspend to disk,
which has both nothing to do with sensible resource management.
It doesn't matter. Current forced suspend to RAM is racy with respect to
wakeup events and should be fixed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe
On Thu, May 27, 2010 at 10:56:37PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 22:36:35 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
No it doesn't. The kernel continues executing anything that was on the
Would you like to come and watch my laptop resume ? With printk's if you
want. You
into suspend. How do we avoid the race in that situation?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/acpi/event notification on resume.
Do we need a better more generic version of the events files - maybe but
thats a rather different kettle of fish to suspend blockers.
It's a requirement for any reasonable alternative approach.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It depends
for this to be handled.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 13, 2010 at 02:34:55PM -0700, Tony Lindgren wrote:
* Matthew Garrett m...@redhat.com [100513 14:16]:
What race-free mechanism do you use to ensure that? It's very easy to
handwave these problems away. It's very difficult to actually write an
implementation that works.
Can
way to do this?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
once the kernel is released.
Deprecating sysfs interfaces can be done within 6 months or so,
especially if there's only one real consumer.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote:
On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote:
Deprecating sysfs interfaces can be done within 6 months or so,
especially if there's only one real consumer.
I'll assume your right (can you give an example
?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote:
On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote:
See feature-removal-schedule.txt. So far we have no indication that it's
going to be replaced, because nobody has actually suggested a working
way to do this better
if that application can't fully
process the packet in a single timeslice?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
loop cripples you. I think we
could implement your suggestion more easily by just giving untrusted
applications an effectively infinite amount of timer slack, but it still
doesn't handle the case where an app behaves excrutiatingly badly.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote:
* Matthew Garrett m...@redhat.com [100513 13:03]:
On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
The system stays running because there's something to do. The system
won't suspend until all the processors
On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote:
* Matthew Garrett m...@redhat.com [100513 13:29]:
And if that's the application that's listening to the network socket
that you want to get a wakeup event from? This problem is hard. I'd love
there to be an elegant solution
68 matches
Mail list logo
