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
Alan Stern writes:
> On Tue, 23 Nov 2010, Kevin Hilman wrote:
>
>> While I like the idea of the symmetry of having both _get_sync() and
>> _put_sync() callable from an interrupt handler, I can't currently think
>> of a situation where we would need to _put_sync() in the ISR. A
>> standard _put()
On Tue, 23 Nov 2010, Kevin Hilman wrote:
> While I like the idea of the symmetry of having both _get_sync() and
> _put_sync() callable from an interrupt handler, I can't currently think
> of a situation where we would need to _put_sync() in the ISR. A
> standard _put() should suffice for all case
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?
>
> That also would work for me, actually.
Okay,
"Rafael J. Wysocki" writes:
> 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
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
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 of rpm_idle() then drivers wouldn't be able to c
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
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 the spinlock in the
> > > IRQ safe case?
> >
>
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 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
> > pm_runtime_irq_safe() function to tell the PM core that a
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
12 matches
Mail list logo
