On Monday, July 11, 2011, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> 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. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
