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. > > 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. :-) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
