Re: pm_runtime_suspended() can be false if RPM_SUSPENDED

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

On Monday, July 11, 2011, Hilman, Kevin wrote:
> On Mon, Jul 11, 2011 at 1:22 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday, July 11, 2011, Kevin Hilman wrote:
> >> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>
> >> [...]
> >>
> >> >>
> >> >> However, based on the pm_runtime_set_active() problem you mentioned
> >> >> above, I'm not sure this will help either, since what the PM domain's
> >> >> noirq callback will want to do will be based on the actual device
> >> >> hardware state, not on the PM core's view of the device state.
> >> >
> >> > Yes.  For devices whose runtime PM is never enabled, this is quite clear
> >> > (we must assume they are operational).  For devices whose runtime PM is
> >> > temporarily disabled and the reenabled, it's not that clear, but at
> >> > least for the system suspend case we may require drivers not to use
> >> > pm_runtime_set_active/suspended() in their callbacks, so that we may
> >> > assume that the status hasn't changed between .suspend() and .resume().
> >> >
> >> > So, I think your approach (to check power.runtime_status) is correct in this
> >> > respect.
> >>
> >> OK, I'll just directly check power.runtime_status in the noirq methods,
> >> since at that point I always know that disable_depth > 0.
> >
> > That's what I wanted to say. :-)  The only problem with that is if
> > CONFIG_PM_RUNTIME is unset, power.runtime_status is not present, so I think
> > we'll need a static inline to work around that.
> >
> 
> OK, I can prepare a patch for a static inline for
> pm_runtime_status_suspended(), unless you have one already in
> progress.

No, I don't, please send me one if you can. :-)

Thanks,
Rafael