"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 think it's important to note the similarities as well as the
differences. Maybe I'm still really blind here, but I cannot see how
they can be completely decoupled.
More specifically, what should be the approach in system suspend when a
device is already runtime suspended? If you treat runtime and system PM
as completely independent, you would have to runtime resume the device
so that it can then be immediately system suspended.
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.
At least for device power domains where the low-power state is identical
between runtime suspend and system suspend, this makes a lot of sense
(to me.) Device power domain ->suspend might look something like this
(obviously not tested):
if (pm_runtime_suspended(dev))
return;
pm_generic_suspend(dev);
magic_device_idle(dev); /* HW-specific, shared with runtime PM */
priv->flags |= MY_DEVICE_SYS_SUSPENDED;
and ->resume():
if (priv->flags & MY_DEVICE_SYS_SUSPENDED) {
magic_device_enable(dev);
pm_generic_resume(dev);
}
Kevin
--
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
