On Friday, August 10, 2012, Ming Lei wrote:
On Fri, Aug 10, 2012 at 3:41 AM, Rafael J. Wysocki r...@sisk.pl wrote:
It just isn't guaranteed that the subsystem callback won't do anything
after driver-runtime_resume completion. I agree that it isn't likely
to happen.
In fact, the
On Thursday, August 09, 2012, Ming Lei wrote:
On Thu, Aug 9, 2012 at 4:16 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, August 08, 2012, Alan Stern wrote:
To be honest, I agree on the idea:
The runtime-resume method does nothing but bring the device
back to full
On Thu, Aug 9, 2012 at 6:46 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, August 09, 2012, Ming Lei wrote:
driver-runtime_resume should be allowed to do I/O things after
the device has been woken up inside driver callback, shouldn't it? If it
isn't allowed, something wrong should
On Thursday, August 09, 2012, Ming Lei wrote:
On Thu, Aug 9, 2012 at 6:46 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, August 09, 2012, Ming Lei wrote:
driver-runtime_resume should be allowed to do I/O things after
the device has been woken up inside driver callback, shouldn't
On Fri, Aug 10, 2012 at 3:41 AM, Rafael J. Wysocki r...@sisk.pl wrote:
It just isn't guaranteed that the subsystem callback won't do anything
after driver-runtime_resume completion. I agree that it isn't likely
to happen.
In fact, the subsystem callback should make sure that don't happen,
On Wednesday, August 08, 2012, Ming Lei wrote:
On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
[...]
and you want to move something out of previous
On Thu, Aug 9, 2012 at 4:16 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, August 08, 2012, Alan Stern wrote:
To be honest, I agree on the idea:
The runtime-resume method does nothing but bring the device
back to full power; it doesn't do any other processing, which
On Tuesday, August 07, 2012, Ming Lei wrote:
On Mon, Aug 6, 2012 at 10:47 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, no, you have completely misunderstood the whole point of this
change.
Sorry, you are right. And the callback should be renamed as
'.runtime_post_resume', which
On Monday, August 06, 2012, Rafael J. Wysocki wrote:
On Monday, August 06, 2012, Alan Stern wrote:
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
[...]
What about the appended experimental patch?
For now, I think it would be best to start with a single func argument.
If it turns
On Tue, 7 Aug 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Yes, I agree, but I don't think it may make .runtime_post_resume
not doable, do I?
No more device PM callbacks, please.
IMO, what the patch is doing is to introduce one callback
On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, that's really not what the patch is doing.
The idea behind the new API is that func will be called as soon as we
know the device is at full power. That could be after the next runtime
resume or it could be
On Tue, 7 Aug 2012, Rafael J. Wysocki wrote:
All those changes (and some of the following ones) are symptoms of a
basic mistake in this approach.
Every time you say something like this (i.e. liks someone who knows better)
s/liks/like/
I kind of feel like being under attach,
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Yes, I agree, but I don't think it may make .runtime_post_resume
not doable, do I?
No more device PM callbacks, please.
IMO, what the patch is doing is to introduce one
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, that's really not what the patch is doing.
The idea behind the new API is that func will be called as soon as we
know the device is at full power. That could be
On Tuesday, August 07, 2012, Alan Stern wrote:
On Tue, 7 Aug 2012, Rafael J. Wysocki wrote:
All those changes (and some of the following ones) are symptoms of a
basic mistake in this approach.
Every time you say something like this (i.e. liks someone who knows
better)
On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Tuesday, August 07, 2012, Ming Lei wrote:
On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Yes, I agree, but I don't think it may make .runtime_post_resume
not doable, do I?
No more device PM
On Sun, Aug 5, 2012 at 11:26 PM, Rafael J. Wysocki r...@sisk.pl wrote:
---
drivers/base/power/runtime.c | 82
+++
include/linux/pm.h |1
include/linux/pm_runtime.h | 14 +++
3 files changed, 90 insertions(+), 7 deletions(-)
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
I don't really think we'll need to store func_sync in dev-power. At least
I don't see a reason to do that at the moment.
You're right; I wasn't thinking straight.
I also think that func_sync() would have to be called if runtime PM is
disabled
On Monday, August 06, 2012, Alan Stern wrote:
On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
[...]
What about the appended experimental patch?
For now, I think it would be best to start with a single func argument.
If it turns out that anyone really needs to have two separate
arguments,
On Mon, Aug 6, 2012 at 10:47 PM, Alan Stern st...@rowland.harvard.edu wrote:
No, no, you have completely misunderstood the whole point of this
change.
Sorry, you are right. And the callback should be renamed as
'.runtime_post_resume', which should do something I/O related in
theory just after
On Friday, August 03, 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much more complicated than the logic involved in
On Friday, August 03, 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much
On Sat, 4 Aug 2012, Rafael J. Wysocki wrote:
On Friday, August 03, 2012, Ming Lei wrote:
On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
Hmmm. You'd probably want a version that does a get at the same
On Sat, 4 Aug 2012, Rafael J. Wysocki wrote:
That wasn't what he meant. What if the code needs to run in the _same_
context as the caller? For example, with a spinlock held.
I see. I think it wouldn't be unreasonable to require that func should take
all of the necessary locks by
On Saturday, August 04, 2012, Alan Stern wrote:
On Sat, 4 Aug 2012, Rafael J. Wysocki wrote:
That wasn't what he meant. What if the code needs to run in the _same_
context as the caller? For example, with a spinlock held.
I see. I think it wouldn't be unreasonable to require that
On Thu, 2 Aug 2012, Alan Stern wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much more complicated than the logic involved in setting up
On Fri, 3 Aug 2012, Ming Lei wrote:
On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
Hmmm. You'd probably want a version that does a get at the same
time. I suppose you would call func directly if the device was
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
I don't know about that -- the logic involved in doing the processing
within the resume callback isn't terribly complicated. At least, not
much more complicated than the logic involved in setting up a custom
work routine as you suggest.
On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:
Hmmm. You'd probably want a version that does a get at the same
time. I suppose you would call func directly if the device was already
resumed, without going through the
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it is
On Wednesday, August 01, 2012, Alan Stern wrote:
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current
On Sunday, July 29, 2012, Rafael J. Wysocki wrote:
On Sunday, July 29, 2012, Alan Stern wrote:
On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
The difference is, if you use _put_sync(), you need to wait the extra 10
ms
for local_pci_probe() to return (if the parent is actually
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it is quite questionable, because
either we want to resume the device immediately, for which
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it is quite questionable,
because
either we want to
On Tuesday, July 31, 2012, Rafael J. Wysocki wrote:
On Tuesday, July 31, 2012, Alan Stern wrote:
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
Now it occured to me that perhaps we don't need the current asynchronous
pm_runtime_get() at all. The usefulness of it
35 matches
Mail list logo
