On Friday, February 25, 2011, Nishanth Menon wrote:
opp_find_freq_exact documentation has is_available instead
of available. This also fixes warning with the kernel-doc:
scripts/kernel-doc drivers/base/power/opp.c /dev/null
Warning(drivers/base/power/opp.c:246): No description found for
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
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
On Friday, February 11, 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
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
On Saturday, February 12, 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, February 11, 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
On Monday, January 31, 2011, Alan Stern wrote
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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
[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 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
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
-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 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
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, June 10, 2010, Neil Brown wrote:
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da
On Thursday, June 10, 2010, Alan Stern wrote:
On Thu, 10 Jun 2010, Rafael J. Wysocki wrote:
Moreover, having thought a bit more about the power manager in user space
concept I'm not sure if it really is that better than the original wakelocks
idea. Namely, it only repaces a kernel-based
On Thursday, June 10, 2010, Mark Brown wrote:
On Thu, Jun 10, 2010 at 10:59:43AM +0200, Rafael J. Wysocki wrote:
So, for a phone-like system, where you'd generally want to simplify user
space,
having a power manager in the kernel seems to make sense to me.
I'm not clear where
On Thursday, June 10, 2010, Neil Brown wrote:
On Thu, 10 Jun 2010 10:59:43 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, June 10, 2010, Neil Brown wrote:
On Wed, 9 Jun 2010 11:40:27 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 09 June 2010, Felipe
On Wednesday 09 June 2010, Felipe Contreras wrote:
On Wed, Jun 9, 2010 at 6:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, 8 Jun 2010, da...@lang.hm wrote:
having suspend blockers inside the kernel adds significant complexity, it's
worth it only if the complexity buys
On Tuesday 08 June 2010, Arve Hjønnevåg wrote:
2010/6/6 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
...
If individual processes are frozen, we run into problems that we
cannot run into if we freeze and thaw all processes.
Not individual processes
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/4 Matt Helsley matth...@us.ibm.com:
On Fri, Jun 04
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
Arve, we're still learning you have some more
On Sunday 06 June 2010, Matthew Garrett wrote:
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
Yes.
On 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, Rafael J. Wysocki wrote:
snip
On Saturday 05 June 2010, Felipe Contreras wrote:
On Mon, May 31, 2010 at 11:47 PM, Florian Mickler flor...@mickler.org wrote:
On Mon, 31 May 2010 22:12:19 +0200
Florian Mickler flor...@mickler.org wrote:
If I have a simple shell script then I don't wanna jump through
hoops just to please
On Saturday 05 June 2010, Peter Zijlstra wrote:
On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
I have seen recent proposals that don't require changing the whole
user-space. That might actually be used by other players.
Sure, an approach benefitting more platforms than
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 in the very general terms:
(1) Use the cgroup freezer to suspend the untrusted apps (ie.
the ones
On Sunday 06 June 2010, Brian Swetland wrote:
On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a
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:
On Fri, Jun 4, 2010 at 5:05 PM, Thomas
On Sunday 06 June 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:
...
So taking your example:
Event happens and gets
On Friday 04 June 2010, Peter Zijlstra wrote:
On Fri, 2010-06-04 at 01:23 +0200, Ingo Molnar wrote:
Btw., i'd like to summarize the scheduler based suspend scheme proposed by
Thomas Gleixner, Peter Zijlstra and myself. I found no good summary of it in
the big thread, and there are also new
On Wednesday 02 June 2010, Neil Brown wrote:
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
I think you have acknowledged that there is a race with suspend - thanks.
Next step was can it be closed.
You
On Wednesday 02 June 2010, Neil Brown wrote:
On Tue, 1 Jun 2010 10:47:49 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
...
So yes, there are different use cases and we should support all of them,
both I shut the lid and my laptop really stays asleep and I never miss a
TXT because my
On Thursday 03 June 2010, Neil Brown wrote:
On Wed, 2 Jun 2010 22:41:14 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 02 June 2010, Neil Brown wrote:
- Would this fix the bug??
- and address the issues that suspend-blockers was created to address
On Tuesday 01 June 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Monday 31 May 2010, Neil Brown wrote:
On Thu, 27 May 2010 23:40:29 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Thu, 27 May 2010, Rafael J. Wysocki
On Tuesday 01 June 2010, Alan Stern wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
As I said before, we generally can't prevent such things from happening,
because even if we handle the particular race described above, it still is
possible that the event will be lost if it arrives just a
201 - 300 of 351 matches
Mail list logo
