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'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. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
