Re: Question about expected behavior when PM runtime is disabled

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Tuesday, June 21, 2011, Kevin Hilman wrote:
> "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)

We probably won't, but I'm not sure about .suspend() and .resume() yet.

Well, there are different things to take into consideration.  Please
see this message, for example: https://lkml.org/lkml/2011/6/20/328 (I should
have CCed it to you, sorry about that).

Thanks,
Rafael