On Monday, August 13, 2012, Alan Stern wrote:
> On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
>
> > > I guess the best we can say is that if you call pm_runtime_barrier()
> > > after updating the dev_pm_ops method pointers then after the barrier
> > > returns, the old method pointers will not
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
> > I guess the best we can say is that if you call pm_runtime_barrier()
> > after updating the dev_pm_ops method pointers then after the barrier
> > returns, the old method pointers will not be invoked and the old method
> > routines will not be
On Monday, August 13, 2012, Alan Stern wrote:
> On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
>
> > > __pm_runtime_barrier() has never made very strong guarantees about
> > > runtime_resume callbacks. But the kerneldoc does claim that any
> > > pending callbacks will have been completed, and
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
> > __pm_runtime_barrier() has never made very strong guarantees about
> > runtime_resume callbacks. But the kerneldoc does claim that any
> > pending callbacks will have been completed, and that claim evidently is
> > violated in the
On Monday, August 13, 2012, Alan Stern wrote:
> On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
>
> > > Firstly, the patch doesn't do anything in the case where the device is
> > > already at full power.
> >
> > This is intentional, because I'm not sure that the code to be run
> > if
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
> > Firstly, the patch doesn't do anything in the case where the device is
> > already at full power.
>
> This is intentional, because I'm not sure that the code to be run
> if pm_runtime_get() returns 1 should always be pm_runtime_work().
>
> For
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
Firstly, the patch doesn't do anything in the case where the device is
already at full power.
This is intentional, because I'm not sure that the code to be run
if pm_runtime_get() returns 1 should always be pm_runtime_work().
For example,
On Monday, August 13, 2012, Alan Stern wrote:
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
Firstly, the patch doesn't do anything in the case where the device is
already at full power.
This is intentional, because I'm not sure that the code to be run
if pm_runtime_get() returns 1
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
__pm_runtime_barrier() has never made very strong guarantees about
runtime_resume callbacks. But the kerneldoc does claim that any
pending callbacks will have been completed, and that claim evidently is
violated in the rpm_resume(parent,0)
On Monday, August 13, 2012, Alan Stern wrote:
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
__pm_runtime_barrier() has never made very strong guarantees about
runtime_resume callbacks. But the kerneldoc does claim that any
pending callbacks will have been completed, and that claim
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
I guess the best we can say is that if you call pm_runtime_barrier()
after updating the dev_pm_ops method pointers then after the barrier
returns, the old method pointers will not be invoked and the old method
routines will not be running.
On Monday, August 13, 2012, Alan Stern wrote:
On Mon, 13 Aug 2012, Rafael J. Wysocki wrote:
I guess the best we can say is that if you call pm_runtime_barrier()
after updating the dev_pm_ops method pointers then after the barrier
returns, the old method pointers will not be invoked
On Sunday, August 12, 2012, Alan Stern wrote:
> On Thu, 9 Aug 2012, Rafael J. Wysocki wrote:
>
> > There are some known concerns about this approach.
> >
> > First of all, the patch at
> >
> > https://patchwork.kernel.org/patch/1299781/
> >
> > increases the size of struct device by the size
On Thu, 9 Aug 2012, Rafael J. Wysocki wrote:
> There are some known concerns about this approach.
>
> First of all, the patch at
>
> https://patchwork.kernel.org/patch/1299781/
>
> increases the size of struct device by the size of a pointer, which may seem
> to
> be a bit excessive to
On Thu, 9 Aug 2012, Rafael J. Wysocki wrote:
There are some known concerns about this approach.
First of all, the patch at
https://patchwork.kernel.org/patch/1299781/
increases the size of struct device by the size of a pointer, which may seem
to
be a bit excessive to somebody,
On Sunday, August 12, 2012, Alan Stern wrote:
On Thu, 9 Aug 2012, Rafael J. Wysocki wrote:
There are some known concerns about this approach.
First of all, the patch at
https://patchwork.kernel.org/patch/1299781/
increases the size of struct device by the size of a pointer,
Hi all,
On Thursday, August 09, 2012, Rafael J. Wysocki wrote:
>
> Unfortunately, pm_runtime_get() is not a very useful interface,
> because if the device is not in the "active" state already, it
> only queues up a work item supposed to resume the device. Then,
> the caller doesn't really know
Hi all,
On Thursday, August 09, 2012, Rafael J. Wysocki wrote:
Unfortunately, pm_runtime_get() is not a very useful interface,
because if the device is not in the active state already, it
only queues up a work item supposed to resume the device. Then,
the caller doesn't really know when
18 matches
Mail list logo
