On Thu, Jun 09, 2011 at 09:56:48AM -0400, Alan Stern wrote: > On Wed, 8 Jun 2011, Kevin Hilman wrote: > > Runtime suspend > > 2. activity finishes > > system suspend [echo mem > /sys/power/state] > > 2. prevent future activity, halt/wait for current activity > > The only difference is step 2. > That _is_ the main difference, and it's a big one. (As Magnus pointed > out, wakeup-enabling is another difference). ... > They don't have to be decoupled, and indeed they can share code. The > point Rafael and I are making is that they have to use different > callback pointers, which gives you a chance to handle the differences > as well as the similarities. It seems like everyone's agreeing with each other here - from the user side the request seems to be largely for core infastructure like UNIVERSAL_DEV_PM_OPS() (which I'm not sure is a good idea any more given that it doesn't do anything to handle the runtime/system interaction?). Right now this all feels like more work than it should be in simpler drivers. > > For many (if not all) devices though, what I suspect we would want is > > for devices that are runtime suspended to stay runtime suspended across > > a system suspend *and* resume. That would mean that the device power > > domain would not call system PM callbacks on devices that are runtime > > suspended. > No, it's generally agreed that _all_ devices should return to full > power during system resume -- even if they were runtime suspended > before the system sleep. This also is explained in the Documentation > files. What is the reasoning behind this agreement? It's not immediately obvious why this is useful. -- 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
