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

[Rafael J. Wysocki]

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/