2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote:
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Fri, 2011-08-05 at 00:17 -0700, Arve Hjønnevåg wrote:
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote:
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve Hjønnevåg a...@android.com
---
drivers/video/omap2/dss/dsi.c | 7 ++-
1 files changed, 6 insertions
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve Hjønnevåg a...@android.com
---
drivers/video/omap2/dss/dsi.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c16b933..6975645
not respecting the scheduler and timers.
This is no longer the case. Both the Nexus-S and Xoom enter lower
power states from suspend than idle.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
Without this change a saw an 18% increase in idle power consumption
on one deivce when trace support is compiled into the kernel. Now
I see the same increase only when tracing.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c |4 ++--
1 files changed, 2 insertions
On Tue, Feb 15, 2011 at 5:50 AM, Alexander Shishkin virtu...@slind.org wrote:
On Mon, Feb 14, 2011 at 10:11:12PM -0800, Arve Hjønnevåg wrote:
Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything
If clk_get fail, assume the etb does not need a separate clock.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 11db628..d4ec368
On some systems kernel code is considered secure, and this code
already limits tracing to the kernel text segment which results
in no trace data.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
already
been returned.
This also fixes the read function so it works when the trace buffer is
larger than the buffer passed in from user space. The old version
would reset the trace buffer pointers after every read, so the second
call to read would always return 0.
Signed-off-by: Arve Hjønnevåg
Trace kernel text segment by default as before, allow tracing of other
ranges by writing a range to /sys/devices/etm/trace_range, or to trace
everything by writing 0 0.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c | 49
reset.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 8126beb..4ad1257 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -44,6
If more than one ETM or PTM are present, configure all of them
and enable the formatter in the ETB. This allows tracing on dual
core systems (e.g. omap4).
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/include/asm/hardware/coresight.h | 16 ++-
arch/arm/kernel/etm.c
It is not safe to call etm_lock or etb_lock without holding the
mutex since another thread may also have unlocked the registers.
Also add some missing checks for valid etb_regs in the etm sysfs
entries.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/kernel/etm.c | 57
The old code enabled data tracing, but did not configure the
range. We now configure it to trace all data addresses by default,
and add a trace_data_range attribute to change the range or disable
data tracing.
Signed-off-by: Arve Hjønnevåg a...@android.com
---
arch/arm/include/asm/hardware
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
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
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
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
), the difference should be hidden to the rest of userspace.
what am I missing here?
The current user space interface does not require that clients
register the file descriptors that they get wakeup events from with
another process.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line
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
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/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
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
don't even need to use cgroups. The existing PM
implementation allows a user process to freeze everything but itself;
that's how swsusp and related programs work.
This is still a big-hammer sort of approach, but it doesn't require any
kernel changes.
Alan Stern
--
Arve Hjønnevåg
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
, otherwise it never gets consumed since user-space
is frozen.
--
Arve Hjønnevåg
--
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
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
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
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 sane and idle when there is
nothing
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Sat, 5 Jun
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, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Sat, 5 Jun
2010/6/5 Arjan van de Ven ar...@infradead.org:
On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hjønnevåg a...@android.com wrote:
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/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:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Why is it a BUG in the trusted app, when I initiate a download and put
the phone down
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:
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote
2010/6/5 Arjan van de Ven ar...@infradead.org:
On Sat, 5 Jun 2010 15:39:44 -0700
Arve Hjønnevåg a...@android.com wrote:
For example if the Adobe Flash player puts a timer every 10
milliseconds (yes it does that), and you give it a 3.99 seconds
range, it will fire its timers every 4
,
visit http://www.lesswatts.org
--
Arve Hjønnevåg
--
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
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, 2010 at 05:39:17PM -0700, 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
justification for the crapplication to run
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:
Well, that's simply an application bug which sucks battery with or
without suspend blockers. So it's unrelated to the freezing of
untrusted apps while
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:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
Cross app calls
will do.
Thanks,
Ingo
--
Arve Hjønnevåg
--
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
2010/6/4 Dmitry Torokhov dmitry.torok...@gmail.com:
On Wed, Jun 02, 2010 at 07:44:59PM -0700, Arve Hjønnevåg wrote:
On Wed, Jun 2, 2010 at 4:32 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
On Wed, Jun 02, 2010 at 09:05:21PM +0200, Florian Mickler wrote:
On Wed, 2 Jun 2010 21:02:24
block suspend until we processed the incoming phone call
notification, the phone may never ring (some devices will send a new
message every few seconds for this, so on those devices it would just
delay the ringing).
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe
2010/6/4 Peter Zijlstra pet...@infradead.org:
On Fri, 2010-06-04 at 01:56 -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar mi...@elte.hu wrote:
* Arve Hj?nnev?g a...@android.com wrote:
[...]
Why do you need to track input wakeups? It's rather fragile
hurdle is how
to handle dependencies between processes that gets frozen and
processes that don't get frozen.
--
Arve Hjønnevåg
--
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
2010/6/4 Thomas Gleixner t...@linutronix.de:
Arve,
On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
Here's my idea
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
snip
With the cgroup freezer you can suspend them right
problems. I've frankly
tried to avoid the whole discussion until Andrew pulled me in yesterday.
Linus
--
Arve Hjønnevåg
--
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
values for this?
--
Arve Hjønnevåg
--
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
();
if (error)
goto Finish;
--
Arve Hjønnevåg
--
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
2010/6/2 Thomas Gleixner t...@linutronix.de:
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de
wrote:
On Mon, 31 May 2010, James
2010/6/2 Thomas Gleixner t...@linutronix.de:
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J
2010/6/2 Neil Brown ne...@suse.de:
On Wed, 2 Jun 2010 00:05:14 -0700
Arve Hjønnevåg a...@android.com wrote:
On Tue, Jun 1, 2010 at 10:32 PM, Neil Brown ne...@suse.de wrote:
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Tue, 1 Jun 2010, Neil Brown
2010/6/2 Thomas Gleixner t...@linutronix.de:
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
2010/6/2 Thomas Gleixner t...@linutronix.de:
On Tue, 1 Jun 2010, Arve Hjønnevåg wrote:
Because suspend itself causes you to not be idle you cannot abort
suspend just because you are not idle anymore
2010/6/2 Thomas Gleixner t...@linutronix.de:
On Wed, 2 Jun 2010, Arve Hjønnevåg wrote:
2010/6/2 Neil Brown ne...@suse.de:
There would still need to be some sort of communication between the the
suspend daemon on any event daemon to ensure that the events had been
processed. This could
2010/6/2 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-06-02 at 01:54 -0700, Arve Hjønnevåg wrote:
No I want you to stop confusing low power idle modes with suspend.
I think it is you who is confused. For power management purposes suspend
is nothing more but a deep idle state.
No, idle
On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley james.bottom...@suse.de wrote:
On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote:
On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley james.bottom...@suse.de wrote:
On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:
No, they have
is entered
if the scan detected that no keys are pressed. The driver could be
modified to stop the scan on suspend and forcibly put the device back
in no-keys-pressed state, but pressing additional keys connected to
the same input can no longer generate any events (the input does not
change).
--
Arve
interface for stats so this is not an
immediate requirement. The suspend blocker debugfs interface is just
as good as the proc interface we have for wakelocks.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
structure.
--
Arve Hjønnevåg
--
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
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think it makes more sense to block suspend while wakeup events
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote:
On Mon, 31 May 2010, James Bottomley wrote:
For MSM hardware, it looks possible to unify the S and C states by doing
2010/6/1 James Bottomley james.bottom...@suse.de:
On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de
wrote:
On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
On Tuesday 01 June 2010, James Bottomley
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
On Saturday 29 May 2010, Arve Hjønnevåg wrote:
2010/5/29 Rafael J. Wysocki r...@sisk.pl:
On Saturday 29 May 2010, Arve Hjønnevåg wrote:
2010/5/28 Rafael J. Wysocki r...@sisk.pl:
On Friday 28 May 2010, Arve Hjønnevåg wrote:
On Fri, May 28, 2010
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think it makes more sense to block suspend while wakeup events are
pending than blocking it everywhere timers are used by code that could
be called while
reliable alarms are useful (dvr application).
--
Arve Hjønnevåg
--
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
originally added wakelocks because the
hardware we had at the time had much lower power consumption in
suspend then idle, but we still use suspend because it saves power.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
2010/5/29 Rafael J. Wysocki r...@sisk.pl:
On Saturday 29 May 2010, Arve Hjønnevåg wrote:
2010/5/28 Rafael J. Wysocki r...@sisk.pl:
On Friday 28 May 2010, Arve Hjønnevåg wrote:
On Fri, May 28, 2010 at 1:44 AM, Florian Mickler flor...@mickler.org
wrote:
On Thu, 27 May 2010 20:05:39 +0200
is not an atomic operation. User space is frozen before
freezable kernel threads both of these happen before drivers are
suspended.
--
Arve Hjønnevåg
--
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
of
sheduled timers
suspend-blockers: must not be activated
Now all transitions and opportunistic suspend could be handled by the
same algorithms.
Would this work?
I'm not sure what you mean.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux
that
progress will have been made before it considers going back to sleep
again. Right now its about ten seconds in each direction plus other costs
(wear on LCD backlight, disc parking etc).
I'm not sure what you are trying to say here. Are you saying your
laptop enters S3 from idle?
--
Arve
by this, but I think the
current implementation is useful as is (it could even be useful to
someone working on a generic constraints framework).
--
Arve Hjønnevåg
--
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
if the button press happend before this line:
count2 = tasks to QS_NONE | QS_NOTCHANGED
As far as I can tell this is the same race I described where you just
told me to read down a paragraph.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap
visible. The race exist on
your laptop as well.
--
Arve Hjønnevåg
--
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
2010/5/28 Florian Mickler flor...@mickler.org:
On Fri, 28 May 2010 02:18:06 -0700
Arve Hjønnevåg a...@android.com wrote:
IMO, the whole concept is defining 2 modes of operation:
1. user interacts with the device (at least one suspend block active)
2. user doesn't interact
://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Arve Hjønnevåg
--
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
or
even surpass it, but we still need suspend on some hardware, and we
would get event better results by using these solutions in addition to
suspend compared to using them instead of suspend.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
2010/5/28 Rafael J. Wysocki r...@sisk.pl:
On Friday 28 May 2010, Arve Hjønnevåg wrote:
On Fri, May 28, 2010 at 1:44 AM, Florian Mickler flor...@mickler.org wrote:
On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
...
To integrate this with the current way
.
--
Arve Hjønnevåg
--
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
.
--
Arve Hjønnevåg
--
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
are serious, since the all the runqueues are never
empty while suspending, this would disable opportunistic suspend
altogether.
--
Arve Hjønnevåg
--
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
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will lead to a scattering of suspend
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:06 -0700, Arve Hjønnevåg wrote:
I was not talking about our user-space code. Suspend has to be called
by a running thread, so at least one runqueue is not empty.
But why would you need to suspend if the machine is fully
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead of
milliseconds to seconds
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we
/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Arve Hjønnevåg
--
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
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:53 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:40 -0700, Arve Hjønnevåg wrote:
2010/5/26 Peter Zijlstra pet...@infradead.org:
On Wed, 2010-05-26 at 03:25 -0700
2010/5/26 Alan Cox a...@lxorguk.ukuu.org.uk:
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from
use it on a desktop.
--
Arve Hjønnevåg
--
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
there are unprocessed input event you now have
to make sure all code that can block any of the threads involved in
processing those event don't wait on a non critical timer.
--
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
suspend, but if
you don't use suspend at all, the wakelocks have no effect and all the
drivers will work correctly.
If the driver is added you want to make sure the benefit is there and
testable for all userspaces.
Agreed.
thanks,
greg k-h
--
Arve Hjønnevåg
--
To unsubscribe from this list
be freed. The old code used
the sum of rss for the killable processes which is not accurate
either.
--
Arve Hjønnevåg
--
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
94 matches
Mail list logo
