Re: Question about expected behavior when PM runtime is disabled

[Kevin Hilman <khilman@ti.com>]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Friday, June 17, 2011, Alan Stern wrote:
>> On Tue, 14 Jun 2011, Rafael J. Wysocki wrote:
>> 
>> > > Then you suggest:
>> > > 
>> > > 	Call pm_runtime_disable after .suspend;
>> > > 
>> > > 	Call pm_runtime_get_noresume and pm_runtime_enable before
>> > > 	.resume;
>> > > 
>> > > 	Call pm_runtime_put_sync after .complete.
>> > > 
>> > > Right?
>> > 
>> > Yes, that would be resonable IMO.
>> 
>> This turns out to be harder than it looks.  If an error occurs, we may
>> run the complete callback for devices that never were suspended or
>> resumed and hence never had their usage_count incremented.  How can we
>> tell that we need to skip the pm_runtime_put_sync for these devices?
>> 
>> Would it be okay to call pm_runtime_put_sync immediately after the
>> resume callback instead of after complete?
>
> Yes, it would.
>
> That said we may be better off by simply reverting commit
> e8665002477f0278f84f898145b1f141ba26ee26 (PM: Allow pm_runtime_suspend() to
> succeed during system suspend).

I'm OK with blocking runtime PM requests after .suspend (and unblocking
before .resume) e.g. protecting the _noirq callbacks, but I hope we
don't have to go back to blocking them before .prepare (and unblocking
after .complete)

Kevin