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
On Thu, 27 May 2010 19:25:27 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 19:21 +0200, Florian Mickler wrote:
On Thu, 27 May 2010 18:45:25 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
The whole notion of treating suspend to RAM any different than a
What is a Correctly implemented driver in this case? One that receives
a wakeup event and then prevents suspend being entered until userspace
has acknowledged that event? Because that's what an in-kernel suspend
blocker is.
Kernel side maybe - but even then its a subset of expressing
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:31 +0100, Matthew Garrett wrote:
Even if we could use suspend-via-deep-idle-state on PCs,
( see Alan Cox's argument on PCs )
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
You
On Thu, 2010-05-27 at 18:40 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the sleep
key, I need to
On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox 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. And from a purely practical point of view,
since the
On Thu, 2010-05-27 at 19:42 +0200, Florian Mickler wrote:
If in the imaginery situation where userspace can aquire certain
wakeup-constraints and loose certain wakeup-constraints, then it could
be that the system enters suspend without empty runqueues.
No. Wakeup constaints simply delay
On Thu, 2010-05-27 at 13:44 -0400, Alan Stern wrote:
You close your laptop's lid and throw the machine into a backpack. At
that time you want it to suspend even though it may not be idle.
We've been trying to tell you you don't need that.
And I'm trying to tell you that you do.
Shall
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
On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
handler gets run, handler generates a task wakeup, runqueue isn't empty,
we run stuff.
If you're using idle-based suspend without any forced idling or
network packet arrives. The difference between these scenarios is large.
Your application seems to change desired outcome every email. Sorry but
you need to explicitly explain and define a policy in full that we can
test ideas against. Otherwise this is useless.
If you have wake-on-lan then
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, a well behaved app would have. I thought we all agreed that
well behaved
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
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
On Thu, 27 May 2010 18:40:19 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:15:31PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
My question was about explicit suspend states, not implicitly handling
an identical state based on scheduler constraints.
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, a
On Thu, 2010-05-27 at 18:57 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
If you want to support forced suspend for laptops and you want to
On Thu, 2010-05-27 at 18:54 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:52:09PM +0200, Peter Zijlstra wrote:
How so, event happens on hardware level, IRQ gets raised, CPU wakes up,
handler gets run, handler generates a task wakeup, runqueue isn't empty,
we run stuff.
If
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:24:02PM +0200, Thomas Gleixner wrote:
Oh no. They paper over a short coming. If there is a pending event,
the kernel knows that. It just does not make use of this
information. Blockers just paper over this by
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Thomas Gleixner wrote:
Crap. Stop beating on those lost wakeup events. If we lose them then
the drivers are broken and do not handle the switch over correctly. Or
the suspend mechanism is broken as it does not evaluate the
So PCs with current ACPI don't get opportunistic suspend capability. It
probably won't be supported on the Commodore Amiga either - your point ?
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
On Thu, May 27, 2010 at 07:02:04PM +0100, Alan Cox wrote:
This is still racy. Going back to this:
int input = socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, 0);
char foo;
struct sockaddr addr;
connect (input, addr, sizeof(addr))
while (1) {
if (read(input, foo, 1) 0) {
On Thu, 27 May 2010, Matthew Garrett wrote:
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?
On Thu, 27 May 2010 18:57:19 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
If you want to support forced suspend for laptops
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, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the sleep
key, I need to go to sleep.
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
--
To
On Thu, May 27, 2010 at 08:05:39PM +0200, Thomas Gleixner wrote:
You're just not getting it. If user space has consumed the event is
not relevant at all.
What's relevant is whether the app has processed the event and reacted
accordingly. That's all that matters.
And how do you know that?
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 for then
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' description of how a driver should do the state
transition.
So either we
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.
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 06:49:18PM +0100, Alan Cox 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. And from a
On Thu, May 27, 2010 at 07:17:16PM +0100, Alan Cox 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 suspend implementation.
If one works so does the
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 its a buggy app, who cares about misbehaviour in a
buggy app?
If it
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 6:54 PM, Sukumar Ghorai s-gho...@ti.com wrote:
[...]
-static unsigned gpmc_cs_map;
+static unsigned int gpmc_cs_map; /* flag for cs which are
initialized */
Tab should be after 'int', not before.
[...]
@@ -456,13 +565,22 @@
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. And
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
On Thu, May 27, 2010 at 05:16:15PM +0100, Alan Cox wrote:
So you need
Userspace - QoS guarantee expression, implied resource
expression via device use. *NO* knowledge of
device or platform in the application
I have a pile of use cases where
Matthew Garrett mj...@srcf.ucam.org writes:
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.
And the
On Thu, 27 May 2010, Matthew Garrett wrote:
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
On Thu, 27 May 2010, Matthew Garrett wrote:
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
No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
may also be in response to a 30 minute timeout
On Thu, May 27, 2010 at 07:48:40PM +0100, Alan Cox wrote:
The application is a network monitoring app that renders server state
via animated bouncing cows. The desired behaviour is that the
application will cease to be scheduled if the session becomes idle
(where idle is defined as the
On Thu, 27 May 2010, Alan Cox wrote:
No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
may also
On Thu, 27 May 2010 19:17:58 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
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
If one works so does 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
On Thu, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
If you want to support forced suspend for laptops and you want to avoid
the risk
On Thu, May 27, 2010 at 07:56:58PM +0100, Matthew Garrett wrote:
Even if it's using poll, it could block purely on the display if X turns
the screen off between poll() waking and the write being made.
That's what fcntl(fd, F_SETFL, O_NONBLOCK) is for.
--
To unsubscribe from this list: send
On Thu, 27 May 2010, Alan Cox wrote:
Rather than continue going around in circles, let's agree that what the
Android people want is a new version of forced suspend -- not a
I don't think this is true. I think that is the root of the problem.
Of course it's true. Just ask Arve -- he
Sigh. No. Forced suspend is a fact of life
'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.
Drivers should enable wakeups before they disable interrupts. So either
the packet hits the IRQ handler and the driver takes a suspend block
On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
The scheduler can happily do this, the power management will also
recognize STOPPED processes as no impediment to suspend.
But wakeup events won't be
On Thu, 27 May 2010 19:23:03 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
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,
We were talking about PCs. Suspend-as-c-state is already implemented for
OMAP.
You were talking about PCs. Some of us are interested in the making
Linux do the right thing not adding platform specific hacks all over the
userspace of all the apps.
So the only thing you are imposing to app
On Thu, May 27, 2010 at 08:50:09PM +0100, Alan Cox wrote:
So I guess if you are driving this rom user space (which I take it you
are given you talk about housekeeping)
foreach app we need to suspend
kick app to suspend (signal)
(policy) kick harder if
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, 27 May 2010, Matthew Garrett wrote:
On Thu, May 27, 2010 at 08:53:11PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
We were talking about PCs. Suspend-as-c-state is already implemented for
OMAP.
Ah, now we talk about PCs. And all of a sudden
From: Menon, Nishanth
Sent: Thursday, May 27, 2010 9:57 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: omap3 pm: dependency between opp layer and cpufreq
[snip]--[snip]
[sp] Responding via webmail.. so the formatting and quotes are non-standard :(
# OPP support in (OMAP3+
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
The event was not lost.
Not lost, but not delivered. So you need your policy agent to send
it will be delivered next time the process wakes. It's not lost.
SIGCONT when you receive any wakeup event, which either means proxying
all your network traffic through your policy agent or having
On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett mj...@srcf.ucam.org 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 for then you don't need to block
applications on
On Thursday 27 May 2010, Thomas Gleixner wrote:
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 16:33 +0100, Alan Cox wrote:
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu,
Hi Govindraj,
Govindraj.R govindraj.r...@ti.com writes:
Patch series is based on remotes/origin/pm-wip/govindraj
branch from Kevin's PM tree.
Patches are tested with 3430SDP.
Have updated 2420/2430 hwmod data files
it would be great if some one can test the same.
OK, I've updated
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
Kevin Hilman khil...@deeprootsystems.com writes:
This series on top of my pm-wip/uart branch fixes up various issues
with UART hwmods for 24xx as well as IDLEST issues after Benoit's
fixes/cleanup series.
Tested on OMAP3 (omap3evm) and OMAP2 (n810/2420).
Note that for OMAP2, this recently
On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote:
Not lost, but not delivered. So you need your policy agent to send
it will be delivered next time the process wakes. It's not lost.
SIGCONT when you receive any wakeup event, which either means proxying
all your network traffic
On Thursday 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 13:29 -0400, Alan Stern wrote:
They may be different conceptually. Nevertheless, Android uses forced
suspend as a form of power saving. Until better mechanisms are in
place, it makes sense.
So let them, doesn't
This series introduces runtime PM support at the platform bus level
for OMAP.
In a nutshell, when using the runtime PM API for any device with an
assocated omap_device (and hwmod), the omap device API will be used to
handle the hardware-level power management of that device, including
managing
When runtime PM for platform_bus was added, it allowed for platforms
to customize the runtime PM methods since they are defined as weak
symbols.
This patch allows platforms to also extend the system PM methods with
custom hooks so runtime PM and system PM extensions can be managed
together by
Implement the new runtime PM framework as a thin layer on top of the
omap_device API. Since we don't have an OMAP-specific bus, override
the runtime PM hooks for the platform_bus for the OMAP specific
implementation.
While the runtime PM API has three main states (idle, suspend, resume)
This
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on suspend and resume.
This allows device drivers to get rid of direct management of their
clocks in their suspend/resume paths, and let omap_device do it for
them.
As part of the runtime PM support, bus-level code can automatically
handle the enable/idle for each omap_device. There are, however, some
special cases where we don't want the bus-level layer to handle this,
and instead handle it manually.
Specific use cases are for omap_devices that are
This series is a set of misc. hwmod fixes needed for functioning
runtime PM on OMAP2 and OMAP3. These were used to get an
omap_device/hwmod-based runtime PM working an tested on OMAP3430
(omap3evm) and OMAP2 (n810)
All of these have been previously posted in various forms, but here
they are all
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still
In the _setup() hook, check for valid IDLEST fields. If not set, use
the module defaults since they are the same as the module defaults
for most hwmods.
Problem found because _wait_target_ready() will fail if IDLEST
fields are not valid.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Some hwmods may be idled/enabled directly from within the core
idle/suspend path. Since interrupts are already disabled here,
the mutex-based locking in hwmod can sleep and will cause
potential deadlocks.
To fix, add a hwmod flag HWMOD_NO_IDLE_LOCKING which indicates to the
hwmod core that no
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3.
The mask used to check this was using the bit position instead of the
bit mask.
This patch fixes the problem by using the bit mask instead of the bit
field.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag,
otherwise _enable() will fail due to failing _wait_target_ready().
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |9 ++---
On Thursday 27 May 2010, Thomas Gleixner wrote:
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a greatly simplified summary of the
comments and objections
On Thursday 27 May 2010, Alan Cox wrote:
Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.
Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.
That isn't helpful. But if you
That's the point -- suspend does not evaluate the system state
correctly because it doesn't have the necessary information. Suspend
The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.
blockers are a way of providing it that
Well, what about when I want the machine to suspend _regardless_ of whether
or not it's idle at the moment? That actually happens quite often to me. :-)
I don't think it helps to combine them for this discussion ?
I don't see much difference between that and ACPI S3 other than the memory
On Thu, 27 May 2010, Matthew Garrett wrote:
Doesn't help - I may be hit by the signal between the poll() unblocking
and me having the opportunity to call sigmask().
ppoll(). This is all existing solved stuff.
Isn't that the inverse of what we want? The application should default
On Thu, 27 May 2010, Matthew Garrett wrote:
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
On Thu, 27 May 2010 13:29:18 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
Does this mean you believe echo mem /sys/power/state is bad and
should be removed? Or echo disk
On Thu, May 27, 2010 at 05:24:28PM -0400, Alan Stern wrote:
Would it help to divide the application into two processes, one of
which receives events and the other does the drawing?
At the point where you're rewriting the application you can just make it
adhere to our current behavioural
On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.
How would we not wake them
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
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
On Thursday 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 13:32 -0400, Alan Stern wrote:
On some platforms (like those with ACPI), deeper power-savings are
available by using forced suspend than by using idle.
Sounds like something that's fixable, doesn't it?
The fix would
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 this
A
On Thu, 27 May 2010, Alan Cox wrote:
That's the point -- suspend does not evaluate the system state
correctly because it doesn't have the necessary information. Suspend
The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.
But
On Thu, May 27, 2010 at 11:33:32PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Alan Stern wrote:
The two of you are talking at cross purposes. Thomas is referring to
idle-based suspend and Matthew is talking about forced suspend.
Yes, and forced suspend to disk is the same as
On Thu, 27 May 2010, Rafael J. Wysocki wrote:
On Thursday 27 May 2010, Thomas Gleixner wrote:
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Felipe Balbi wrote:
On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
If people don't mind, here is a
On Thu, 27 May 2010 22:36:35 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
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
On Thu, 27 May 2010, Thomas Gleixner wrote:
The two of you are talking at cross purposes. Thomas is referring to
idle-based suspend and Matthew is talking about forced suspend.
Yes, and forced suspend to disk is the same as force suspend to disk,
which has both nothing to do with
On Thursday 27 May 2010, Alan Cox wrote:
If one works so does 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
On Thursday 27 May 2010, Thomas Gleixner wrote:
On Thu, 27 May 2010, Alan Stern wrote:
On Thu, 27 May 2010, Thomas Gleixner wrote:
Crap. Stop beating on those lost wakeup events. If we lose them then
the drivers are broken and do not handle the switch over correctly. Or
the
On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up.
Okay, and the kernel never suspends. We _are_ talking about a kind of
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
101 - 200 of 222 matches
Mail list logo
