[RFC][PATCH 0/3] (was: Re: [RFC][PATCH 1/3] PM / sleep: Flags to speed up suspend-resume of runtime-suspended devices)

From: Rafael J. Wysocki
Date: Wed May 07 2014 - 19:17:25 EST


On Wednesday, May 07, 2014 11:43:39 AM Alan Stern wrote:
> On Wed, 7 May 2014, Rafael J. Wysocki wrote:
>
> We seem to be in agreement that this is the way you want to go...
>
> > > All right. Then this seems to be what you want:
> > >
> > > For some devices, it's okay to remain in runtime suspend
> > > throughout a complete system suspend/resume cycle (if the
> > > device was in runtime suspend at the start of the cycle).
> > > We would like to do this whenever possible, to avoid the
> > > overhead of extra power-up and power-down events.
> >
> > Yes.
> >
> > > However, problems may arise because the device's descendants
> > > may require it to be at full power at various points during
> > > the cycle. Therefore the only way to do this safely is if the
> > > device _and_ all its descendants can remain runtime suspended
> > > until the resume stage of system resume.
> >
> > It may not be the only way, but it is *a* way to do this safely.
> >
> > > To this end, introduce dev->power.leave_runtime_suspended.
> > > If a subsystem or driver sets this flag during the ->prepare()
> > > callback, and if the flag is set in all of the device's
> > > descendants, and if the device is still in runtime suspend when
> > > the ->suspend() callback would normally be invoked, then the PM
> > > core will not invoke the device's ->suspend(),
> > > ->suspend_late(), ->suspend_irq(), ->resume_irq(),
> > > ->resume_early(), or ->resume() callbacks. Instead, it will
> > > invoke ->runtime_resume() during the resume stage of system
> > > resume.
> >
> > Yes.
> >
> > > By setting this flag, a driver or subsystem tells the PM core
> > > that the device is runtime suspended, it is in a suitable state
> > > for system suspend (for example, the wakeup setting does not
> > > need to be changed), and it does not need to return to full
> > > power until the resume stage.
> >
> > Yes.
> >
> > > Does that correctly describe what you want to do, the potential
> > > problems, and the proposed solution?
> >
> > Almost. Devices with power.ignore_children set are not covered by this.
>
> I thought they were. In what respect aren't they? You mean because
> they can be runtime suspended while their children remain active?
>
> I don't think that matters here. Suppose a parent device's
> leave_runtime_suspended flag is set but one of its children isn't
> runtime suspended. Then that child's leave_runtime_suspended flag
> won't be set, so the parent device won't meet the criterion for
> skipping the normal PM callbacks.
>
> Or do you mean that a child might expect the parent to be at full power
> when the child is resumed (plus the fact that doing a runtime resume on
> the child will not automatically resume the parent)? That doesn't
> matter either, because the PM core will do a runtime-resume of the
> parent before the child's ->runtime_resume() is called.

OK

> > > If so, then it appears the parent_needed flag is unnecessary.
> >
> > Well, I can agree with that. It wasn't there in my first patchset and I added
> > it kind of in the hope to be able to deal with the ignore_children devices
> > with the help of it.
>
> Yeah. I contributed to that, by not understanding exactly what you
> were trying to accomplish.
>
> > OK, I guess I need to prepare a new version without the parent_needed flag for
> > further discussion. :-)
>
> Consider using the description above (or some variant of it) for the
> new Changelog. IMNSHO it does a much better job of explaining the
> patch than your original version. :-)

Yes, it does and I actually used it with minor modifications. :-)

A refreshed series follows. The reason why I still want pm_runtime_enabled_and_suspended()
is because a device's runtime suspend may (theoretically) complete after its ->prepare()
callback has been executed and I think it's better to avoid resuming it in that case
too if that's not necessary.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/