On Monday, August 16, 2010, Kalliguddi, Hema wrote:
Hi,
-Original Message-
From: Kalliguddi, Hema
Sent: Friday, August 13, 2010 7:08 PM
To: Cousson, Benoit
Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kevin Hilman;
paul.walmsley[p...@pwsan.com]
Subject: RE: [PATCH] :
On Tuesday, August 10, 2010, Kevin Hilman wrote:
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle sequence, interrupts will likely be disabled when
runtime PM for these devices is initiated.
On Thursday, August 19, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Tuesday, August 10, 2010, Kevin Hilman wrote:
When using runtime PM in combination with CPUidle, the runtime PM
transtions of some devices may be triggered during the idle path.
Late in the idle
-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
On Friday, September 03, 2010, Sripathy, Vishwanath wrote:
-Original Message-
From: Jean Delvare [mailto:kh...@linux-fr.org]
Sent: Wednesday, September 01, 2010 2:11 PM
To: Rafael J. Wysocki
Cc: Mark Brown; Kevin Hilman; Sripathy, Vishwanath;
linux-...@vger.kernel.org
On Friday, September 17, 2010, Nishanth Menon wrote:
Mark Brown had written, on 09/17/2010 10:36 AM, the following:
On Thu, Sep 16, 2010 at 08:29:33PM -0500, Nishanth Menon wrote:
+struct opp_def {
+ unsigned long freq;
+ unsigned long u_volt;
+
+ bool enabled;
+};
It
On Saturday, September 18, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 09/17/2010 05:22 PM, the following:
On Friday, September 17, 2010, Nishanth Menon wrote:
Mark Brown had written, on 09/17/2010 10:36 AM, the following:
On Thu, Sep 16, 2010 at 08:29:33PM -0500, Nishanth
[Trimming the CC list.]
On Saturday, September 18, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 09/17/2010 06:07 PM, the following:
...
Apart from this, it might be a good idea to help callers a bit and actually
introduce some sort of locking into the framework.
in OMAP
[Trimming the CC list]
On Saturday, September 18, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 09/17/2010 05:45 PM, the following:
Thanks for your review. few views below..
On Friday, September 17, 2010, Nishanth Menon wrote:
Nishanth Menon had written, on 09/17/2010 10
On Monday, September 20, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
[...]
In terms of the lifetime rules on the nodes in the list:
The list is expected to be maintained once created, entries are
expected
to be added optimally and not expected
On Monday, September 20, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Monday, September 20, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
[...]
In terms of the lifetime rules on the nodes in the list:
The list is expected
On Wednesday, September 22, 2010, Arjan van de Ven wrote:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
[Dropping disc...@lesswatts.org from the CC list.]
On Wednesday, September 22, 2010, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
[Trimming the CC list slightly.]
Hi,
On Wednesday, September 22, 2010, Nishanth Menon wrote:
SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
On Friday, September 24, 2010, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 23 Sep 2010, Kevin Hilman wrote:
...
You're trying to fight the runtime-PM design instead of using it as it
was intended. We already have an API for starting a resume from
On Friday, September 24, 2010, Paul E. McKenney wrote:
On Fri, Sep 24, 2010 at 07:50:40AM -0500, Nishanth Menon wrote:
...
Looks like a good start!!! Some questions and suggestions about RCU
usage interspersed below.
...
+ * Locking: RCU reader.
+ */
+int opp_get_opp_count(struct
On Monday, September 27, 2010, Nishanth Menon wrote:
Paul E. McKenney had written, on 09/25/2010 07:56 PM, the following:
On Sat, Sep 25, 2010 at 10:55:20PM +0200, Rafael J. Wysocki wrote:
On Friday, September 24, 2010, Paul E. McKenney wrote:
On Fri, Sep 24, 2010 at 07:50:40AM -0500
On Monday, September 27, 2010, Alan Stern wrote:
On Fri, 24 Sep 2010, Rafael J. Wysocki wrote:
On Friday, September 24, 2010, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 23 Sep 2010, Kevin Hilman wrote:
...
You're trying to fight the runtime
On Tuesday, September 28, 2010, Alan Stern wrote:
On Mon, 27 Sep 2010, Rafael J. Wysocki wrote:
On Monday, September 27, 2010, Alan Stern wrote:
On Mon, 27 Sep 2010, Rafael J. Wysocki wrote:
...
Given this, I see no point in adding a special per-call flag.
There's another advantage
events to the old ones for
backward compatibility with the existing user apps. The apps should be
converted to the new API asap,
3) update documentation
Sounds reasonable.
Other remarks here below:
On Wed, Sep 22, 2010 at 8:49 PM, Rafael J. Wysocki r...@sisk.pl wrote
On Tuesday, September 28, 2010, Arjan van de Ven wrote:
On 9/28/2010 2:22 PM, Rafael J. Wysocki wrote:
On Tuesday, September 28, 2010, Jean Pihet wrote:
Hi,
Hi,
Here is what I am proposing, in reply to all your comments:
1) rename the events to match Thomas's proposal
On Tuesday, September 28, 2010, Jean Pihet wrote:
Hi,
On Tue, Sep 28, 2010 at 11:22 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, September 28, 2010, Jean Pihet wrote:
Hi,
Hi,
Here is what I am proposing, in reply to all your comments:
1) rename the events to match
On Saturday, September 25, 2010, Kevin Hilman wrote:
Now that we have runtime PM for devices, I'm exploring ways of how to
couple the runtime PM of certain devices with CPUidle transitions.
Ideally, CPUidle should only manage CPU idle states, and device idle
states would be managed separately
Hi,
On Thursday, September 30, 2010, Alan Stern wrote:
This patch (as1431) adds a synchronous runtime-PM interface suitable
for use in interrupt handlers. Four new helper functions are defined:
pm_runtime_suspend_irq(), pm_runtime_resume_irq(),
pm_runtime_get_sync_irq(),
On Thursday, September 30, 2010, Alan Stern wrote:
This patch (as1431) adds a synchronous runtime-PM interface suitable
for use in interrupt handlers. Four new helper functions are defined:
pm_runtime_suspend_irq(), pm_runtime_resume_irq(),
pm_runtime_get_sync_irq(),
On Thursday, September 30, 2010, Alan Stern wrote:
On Thu, 30 Sep 2010, Rafael J. Wysocki wrote:
--- usb-2.6.orig/include/linux/pm.h
+++ usb-2.6/include/linux/pm.h
@@ -485,6 +485,7 @@ struct dev_pm_info {
unsigned intrun_wake:1;
unsigned int
On Friday, October 01, 2010, Alan Stern wrote:
On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
On Thursday, September 30, 2010, Alan Stern wrote:
This patch (as1431) adds a synchronous runtime-PM interface suitable
for use in interrupt handlers. Four new helper functions are defined
On Friday, October 01, 2010, Alan Stern wrote:
On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
If RPM_IRQ is not set, but
power.callbacks_in_irq is set, we should fall back to the normal
behavior
(ie. do not avoid sleeping).
By do not avoid sleeping, do you mean
On Saturday, October 02, 2010, Alan Stern wrote:
On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
...
At the moment it suspends when the network cable is removed from the device
and the hack I mentioned is used during the resume after the cable has been
reinserted (it checks if the cable
On Sunday, October 03, 2010, Alan Stern wrote:
On Sun, 3 Oct 2010, Rafael J. Wysocki wrote:
On Saturday, October 02, 2010, Alan Stern wrote:
On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
...
At the moment it suspends when the network cable is removed from the
device
On Friday, October 01, 2010, Nishanth Menon wrote:
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions.
On Tuesday, October 05, 2010, Rafael J. Wysocki wrote:
On Friday, October 01, 2010, Nishanth Menon wrote:
...
+int opp_init_cpufreq_table(struct device *dev,
+ struct cpufreq_frequency_table **table)
+{
+ struct device_opp *dev_opp;
+ struct opp *opp
On Monday, October 04, 2010, Jean Pihet wrote:
Uses the machine_suspend trace point, from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
kernel/power/suspend.c |3
On Tuesday, October 05, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following:
On Friday, October 01, 2010, Nishanth Menon wrote:
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage
On Wednesday, October 06, 2010, Alan Stern wrote:
On Tue, 5 Oct 2010, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
In my opinion the _irq operations should really be one-shot, without
any looping, waking up
On Wednesday, October 06, 2010, Alan Stern wrote:
On Wed, 6 Oct 2010, Kevin Hilman wrote:
I think I can live with the above restrictions (the _irq methods failing
unless they can immediately run.) For the rare corner cases I've
currently run into, this will work fine as they happen
On Thursday, October 07, 2010, Alan Stern wrote:
On Thu, 7 Oct 2010, Kevin Hilman wrote:
My confusion is not about the use of spinlocks, it's a question of what
is being busy-waited for, and the thread that is being waited for is
going to complete when interrupts are disabled.
Sorry
Hi,
On Wednesday, October 06, 2010, Nishanth Menon wrote:
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon
On Friday, October 08, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Thursday, October 07, 2010, Alan Stern wrote:
On Thu, 7 Oct 2010, Kevin Hilman wrote:
My confusion is not about the use of spinlocks, it's a question of what
is being busy-waited
On Friday, October 08, 2010, Alan Stern wrote:
On Thu, 7 Oct 2010, Rafael J. Wysocki wrote:
If the PM core simply avoids releasing dev-power.lock before
invoking the runtime_suspend or runtime_resume callback, the
end result is almost the same as with busy-waiting
On Friday, October 08, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, October 08, 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Thursday, October 07, 2010, Alan Stern wrote:
On Thu, 7 Oct 2010, Kevin Hilman wrote:
My
On Friday, October 08, 2010, Rafael J. Wysocki wrote:
On Friday, October 08, 2010, Alan Stern wrote:
On Thu, 7 Oct 2010, Rafael J. Wysocki wrote:
If the PM core simply avoids releasing dev-power.lock before
invoking the runtime_suspend or runtime_resume callback
for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J Wysocki, Paul E McKenney for valuable
improvements.
Discussions and comments from:
http://marc.info/?l=linux-omapm
On Monday, October 11, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
[...]
Signed-off-by: Nishanth Menon n...@ti.com
OK
Your error messages are a bit inconsistent (e.g. some of them print the
error code while others don't
On Monday, October 11, 2010, Alan Stern wrote:
On Sat, 9 Oct 2010, Rafael J. Wysocki wrote:
I wonder if we can do the fast suspend and fast resume under the
power.lock spinlock. That would allow us to avoid some complications
related to RPM_RESUMING and RPM_SUSPENDING. Namely
On Tuesday, October 12, 2010, Rafael J. Wysocki wrote:
On Monday, October 11, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
[...]
Signed-off-by: Nishanth Menon n...@ti.com
OK
Your error messages are a bit inconsistent
On Monday, October 25, 2010, Mathieu Desnoyers wrote:
* Ingo Molnar (mi...@elte.hu) wrote:
* Thomas Renninger tr...@suse.de wrote:
On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
New power trace events:
On Monday, October 25, 2010, Arjan van de Ven wrote:
On 10/25/2010 4:03 AM, Thomas Renninger wrote:
On Monday 25 October 2010 12:04:28 Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
New power trace events:
power:processor_idle
power:processor_frequency
On Tuesday, October 26, 2010, Thomas Renninger wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
New power trace events:
power:processor_idle
power:processor_frequency
On Tuesday, October 26, 2010, Thomas Renninger wrote:
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
..
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
On Tuesday, October 26, 2010, Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
-
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra pet...@infradead.org
wrote:
On Tue, 2010-10-26 at 11:56 -0500
On Tuesday, October 26, 2010, Arjan van de Ven wrote:
On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysockir...@sisk.pl wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote
On Wednesday, October 27, 2010, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11
On Wednesday, October 27, 2010, Thomas Renninger wrote:
On Tuesday 26 October 2010 08:57:01 pm Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Thomas Renninger wrote:
Ok, that's at least generic. Needs the review of Rafael, to determine
whether this state value is all we
On Wednesday, October 27, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet
On Wednesday, October 27, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
...
Hrm, then why export pm_runtime_get_noresume() at all ?
Basically, the PM core needs it for some obscure stuff. Beyond that people
really should use it with care (preferably avoid using
On Thursday, October 28, 2010, Thomas Renninger wrote:
Recent changes:
- Enable EVENT_POWER_TRACING_DEPRECATED by default
New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are
On Thursday, October 28, 2010, Rafael J. Wysocki wrote:
On Thursday, October 28, 2010, Thomas Renninger wrote:
Recent changes:
- Enable EVENT_POWER_TRACING_DEPRECATED by default
New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend
C-state/idle
On Friday, November 19, 2010, Alan Stern wrote:
This patch (as1431b) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime-PM callbacks should be invoked with
On Saturday, November 20, 2010, Alan Stern wrote:
On Sat, 20 Nov 2010, Rafael J. Wysocki wrote:
On Friday, November 19, 2010, Alan Stern wrote:
This patch (as1431b) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
On Saturday, November 20, 2010, Alan Stern wrote:
On Sat, 20 Nov 2010, Alan Stern wrote:
On Sat, 20 Nov 2010, Rafael J. Wysocki wrote:
On Friday, November 19, 2010, Alan Stern wrote:
...
I don't think Linus will object to this. What he doesn't like is when
some code drops a lock
On Monday, November 22, 2010, Alan Stern wrote:
On Mon, 22 Nov 2010, Rafael J. Wysocki wrote:
I didn't like this change before and I still don't like it. Quite
frankly, I'm
not sure I can convince Linus to pull it. :-)
Why don't we simply execute the callback under
On Tuesday, November 23, 2010, Alan Stern wrote:
On Tue, 23 Nov 2010, Rafael J. Wysocki wrote:
Moreover, I'm not sure if we need an IRQ safe version of _idle. Why
do
we need it, exactly?
Because pm_runtime_put_sync() calls rpm_idle(). If there were no
irq-safe version
On Wednesday, November 24, 2010, Alan Stern wrote:
On Tue, 23 Nov 2010, Rafael J. Wysocki wrote:
Or maybe you think that when pm_runtime_put_sync detects the
usage_count has decremented to 0 and the device is irq-safe, it should
call rpm_suspend directly instead of calling rpm_idle
On Thursday, November 25, 2010, Oliver Neukum wrote:
Am Donnerstag, 25. November 2010, 16:52:39 schrieb Alan Stern:
When a device is declared irq-safe in this way, the PM core increments
the parent's usage count, so the parent will never be runtime
suspended. This prevents difficult
On Thursday, November 25, 2010, Alan Stern wrote:
This patch (as1431c) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime_suspend and runtime_resume callbacks
On Tuesday, January 04, 2011, Jean Pihet wrote:
Hi,
On Tue, Jan 4, 2011 at 12:29 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger
On Wednesday, January 05, 2011, Jean Pihet wrote:
On Wed, Jan 5, 2011 at 12:01 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, January 04, 2011, Jean Pihet wrote:
Hi,
On Tue, Jan 4, 2011 at 12:29 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
Uses the machine_suspend trace point
On Monday, January 31, 2011, Alan Stern wrote:
On Mon, 31 Jan 2011, Kevin Hilman wrote:
I understand how this works, but frankly I'm still a bit fuzzy on why.
I guess I'm still missing a good understanding of what interfering with a
system power transition means, and why a runtime
On Tuesday 27 October 2009, Dasgupta, Romit wrote:
Ok. Then the following is the refined and probably more appropriate one.
This fixes the point where we need to complete the power transition when
device suspend fails.
Signed-off-by: Romit Dasgupta ro...@ti.com
---
diff --git
On Tuesday 03 November 2009, Dasgupta, Romit wrote:
Subject: Re: [PATCH 1/1] PM: Making bdi threads non-freezable
On Monday 02 November 2009, Dasgupta, Romit wrote:
Fixes the case when bdi threads are in the refrigerator but file system
sync
can happen after this. This is
On Monday 09 November 2009, Dasgupta, Romit wrote:
Really? I believe the ktrhead_should_stop is new rule, and code does
not seem to follow it. Actually, for example audit does not seem to
use kthread_should_stop() at all...
./kernel/rtmutex-tester.c-
./kernel/rtmutex-tester.c-
On Wednesday 11 November 2009, Pavel Machek wrote:
On Wed 2009-11-11 14:00:16, Romit Dasgupta wrote:
Kicks out frozen bdi flusher task out of the refrigerator when the flusher
task
needs to exit.
Signed-off-by: Romit Dasgupta ro...@ti.com
Ok, its slightly interesting, but better
On Wednesday 11 November 2009, Romit Dasgupta wrote:
Hello Rafael,
As suggested I have added the relevant information in the
changelog. The patch is below:
For completness, below is the information from the Romit's introductory
message
(Romit, I really think that should go
On Wednesday 11 November 2009, Jens Axboe wrote:
On Wed, Nov 11 2009, Rafael J. Wysocki wrote:
On Wednesday 11 November 2009, Pavel Machek wrote:
On Wed 2009-11-11 14:00:16, Romit Dasgupta wrote:
Kicks out frozen bdi flusher task out of the refrigerator when the
flusher task
On Thursday 13 May 2010, Matthew Garrett wrote:
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
On Thursday 13 May 2010, Tony Lindgren wrote:
* Alan Stern st...@rowland.harvard.edu [100513 07:11]:
On Wed, 12 May 2010, Paul Walmsley wrote:
Hello,
Some general comments on the suspend blockers/wakelock/opportunistic
suspend v6 patch series, posted here:
On Thursday 13 May 2010, Matthew Garrett wrote:
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.
On Thursday 13 May 2010, Daniel Walker wrote:
On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote:
On Thursday 13 May 2010, Matthew Garrett wrote:
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
On Thursday 13 May 2010, Tony Lindgren wrote:
* Daniel Walker dwal...@fifo99.com [100513 14:28]:
On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote:
Because someone would have to remove suspend blockers (or rather
wakelocks)
from the drivers, test that they work correctly
On Thursday 13 May 2010, Tony Lindgren wrote:
* Rafael J. Wysocki r...@sisk.pl [100513 14:16]:
On Thursday 13 May 2010, Matthew Garrett wrote:
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
On Thursday 13 May 2010, Tony Lindgren wrote:
* Rafael J. Wysocki r...@sisk.pl [100513 14:08]:
On Thursday 13 May 2010, Tony Lindgren wrote:
The difference between echo mem /sys/power/state and suspend blocks
is that with suspend blocks the system keeps running.
Care
On Thursday 13 May 2010, Tony Lindgren wrote:
* Alan Stern st...@rowland.harvard.edu [100513 14:32]:
On Thu, 13 May 2010, Tony Lindgren wrote:
The difference between echo mem /sys/power/state and suspend blocks
is that with suspend blocks the system keeps running.
Irrelevant.
On Thursday 13 May 2010, Tony Lindgren wrote:
* Alan Stern st...@rowland.harvard.edu [100513 14:36]:
On Thu, 13 May 2010, Tony Lindgren wrote:
Well this is an interesting problem, and once solved will be handy
for all kind of things. My worry is that if it's integrated in it's
On Friday 14 May 2010, Tony Lindgren wrote:
* Alan Stern st...@rowland.harvard.edu [100513 14:56]:
On Thu, 13 May 2010, Tony Lindgren wrote:
And that's why
it should be handled by runtime power management instead.
Runtime PM is not capable of freezing userspace and
On Friday 14 May 2010, Mark Brown wrote:
On Thu, May 13, 2010 at 02:46:53PM -0700, Greg KH wrote:
On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote:
You get the driver mainlined, then maintain a small patch to add
wakelocks. Not hard at all , with lots of incentive to do so
On Friday 14 May 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Thursday 13 May 2010, Tony Lindgren wrote:
* Rafael J. Wysocki r...@sisk.pl [100513 14:16]:
[...]
It solves a practical issue that _at_ _the_ _moment_ cannot be solved
differently, while
On Friday 14 May 2010, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Rafael J. Wysocki r...@sisk.pl writes:
On Thursday 13 May 2010, Tony Lindgren wrote:
* Rafael J. Wysocki r...@sisk.pl [100513 14:16]:
[...]
It solves a practical issue that _at_
On Saturday 15 May 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday 14 May 2010, Kevin Hilman wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Rafael J. Wysocki r...@sisk.pl writes:
On Thursday 13 May 2010, Tony Lindgren wrote:
* Rafael J
On Monday 17 May 2010, Brian Swetland wrote:
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote:
...
but can anyone write an app that holds a suspend_blocker ?? If so, then
your goal is already broken, right ? I mean, if anyone can keep a
suspend_blocker held forever,
On Wednesday 19 May 2010, Felipe Balbi wrote:
On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote:
On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
Right, because Firmware writers are from the rugged
On Monday 24 May 2010, Felipe Balbi wrote:
On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
On Saturday 22 May 2010, Arve Hjønnevåg wrote:
This patch series adds a suspend-block api that provides the same
functionality as the android wakelock api. This version adds
On Tuesday 25 May 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Monday 24 May 2010, Felipe Balbi wrote:
On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
On Saturday 22 May 2010, Arve Hjønnevåg wrote:
This patch series adds a suspend-block api
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,
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
1 - 100 of 351 matches
Mail list logo
