Hi Kevin, On Thu, Jun 9, 2011 at 7:50 AM, Kevin Hilman <khilman@xxxxxx> wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> writes: > > [...] > >> you need to separate the system suspend handling from runtime PM. > > /me risks getting yelled at again and jumps back in ;) =) >> Each of them requires a different approach, because the goal is really >> different in both cases (basically, runtime PM triggers when the >> device is _known_ to be idle, while system suspend may trigger while >> it's actually being used). > > OK, but from the driver's perspective, the goals do not seem all that > different to me: > > Runtime suspend > 1. activity > 2. activity finishes > 3. device is _known_ to be idle > 4. trigger device low-power transition > > system suspend [echo mem > /sys/power/state] > 1. activity > 2. prevent future activity, halt/wait for current activity > 3. device is _known_ to be idle > 4. trigger device low-power transition > > The only difference is step 2. In runtime suspend, the activity > finishes on its own, in system suspend, the activity is forcibly > stopped. In either case, after that point the device is known to be > idle, and proceeding from there is identical. IOW, based on the above, > another way of looking at system PM is forcing idle so that runtime PM > can happen. I agree with the view that system wide suspend is similar to force idle in the case of a non-wakeup device. If you flip that around then from a device driver perspective, system wide suspend on a device which is a wakeup source looks like forcing enable. This is how I see the system wide suspend including wakeup support: 1. activity (In case of an ethernet device for instance, the network may be up or down) 2. save current state 3. prevent future activity, halt/wait for current activity 4. device is _known_ to be idle 5. if wakeup is enabled, force enable regardless of state in step 1 above 6. trigger device low-power transition (if possible) For system wide resume: 1. wake up from low-power state (if needed) 2. if wakeup was enabled, force idle - similar to suspend step 3 above 3. device is _known_ to be idle 4. restore state saved in suspend step 2 above 5. activity (Also, make sure no interrupts are lost) The two roles for each wakeup-capable driver, and switching between those adds quite a bit of complexity. The absolute best part is the interrupt leakage between the wakeup state and the real state. Almost impossible to get right. =) / magnus -- 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
