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,
if the device is flagged as power.irq_safe, it will always
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,
if the
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, the
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.
This is slightly more complicated, because suspend is a
On Thu, 7 Oct 2010, Kevin Hilman wrote:
Do you need normal resume to work after atomic suspend, or is it
sufficient that atomic suspend will require atomic resume?
hmm... while I'm definitely needing an atomic resume after a normal
suspend, for now I can't think of a case where a normal
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.
This is
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
Alan Stern st...@rowland.harvard.edu writes:
On Thu, 7 Oct 2010, Kevin Hilman wrote:
Do you need normal resume to work after atomic suspend, or is it
sufficient that atomic suspend will require atomic resume?
hmm... while I'm definitely needing an atomic resume after a normal
suspend,
Alan Stern st...@rowland.harvard.edu writes:
On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
Defer the resume. That's the only thing you can do in any case, whether
you're
going to busy loop or just use a workqueue.
They are not the same. With a busy-wait you handle the device as soon
as
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 to be dense, but can you (re)summarize what you're
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
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 for, and the thread that is being waited for is
going to complete
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 for, and the
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 confusion is not about the use of spinlocks, it's a question of
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 parents etc. I mean, if the parent is not
RPM_ACTIVE,
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
Alan Stern st...@rowland.harvard.edu writes:
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 parents etc.
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 because of a
wakeup IRQ, where we know the device is
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
Alan Stern st...@rowland.harvard.edu writes:
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 because of
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 parents etc. I mean, if the parent is not
RPM_ACTIVE,
the _irq resume should immediately fail and
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
and the hack I mentioned is used during the resume after the
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
and the
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 parents etc. I mean, if the parent is not
RPM_ACTIVE,
the _irq resume should immediately fail and analogously for the _irq
suspend. And so on.
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 is
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:
pm_runtime_suspend_irq(),
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 that
(1) the helper functions should be allowed to sleep,
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 that
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(), pm_runtime_put_sync_irq(),
together with
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 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 intruntime_auto:1;
unsigned intno_callbacks:1;
+
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
34 matches
Mail list logo
