On Monday, October 11, 2010, Alan Stern wrote: > On Sat, 9 Oct 2010, Rafael J. Wysocki wrote: > > > I wonder if we can do the "fast suspend" and "fast resume" under the > > power.lock spinlock. That would allow us to avoid some complications > > related to RPM_RESUMING and RPM_SUSPENDING. Namely, > > if the device is flagged as "power.irq_safe", it will always suspend and > > resume "atomically" under its power.lock spinlock. Then, the status will > > always be either RPM_ACTIVE or RPM_SUSPENDED (or RPM_ERROR, > > which is uninteresting). > > We could do this. It has some disadvantages but they aren't terrible. > > > Also, if "fast suspend" doesn't change the device > > parent's power.child_count, we won't need to worry about parents any more. > > I don't know about that. If the parent's child_count doesn't change > then the parent can never suspend. Of course, if there is no parent or > the parent is disabled for runtime PM then this doesn't matter.
I think the recursive resuming of the parents is inherently nonatomic and it shouldn't be done in the "fast suspend/resume" case. So, I think it might make sense to prevent the parent from ever suspending if children are supposed to use the "fast" ops. > > I'm still not sure what to do with _idle() in that case. > > Clearly we should not hold the spinlock while running the runtime_idle > callback. That would make it impossible for the callback to ask for a > suspend. That's correct. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
