On Friday, May 09, 2014 03:48:21 PM Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> writes: > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to > > resume all runtime-suspended devices during system suspend, mostly > > because those devices may need to be reprogrammed due to different > > wakeup settings for system sleep and for runtime PM. > > > > For some devices, though, it's OK 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. > > > > 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 > > most straightforward way to do this safely is if the device and all its > > descendants can remain runtime suspended until the resume stage of system > > resume. > > > > 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 at the beginning of the ->suspend() > > callback, that callback is allowed to return 0 without clearing > > power.leave_runtime_suspended and without changing the state of the > > device, unless the current state of the device is not appropriate for > > the upcoming system sleep state (for example, the device is supposed to > > wake up the system from that state and its current wakeup settings are > > not suitable for that). Then, the PM core will not invoke the device's > > ->suspend_late(), ->suspend_irq(), ->resume_irq(), ->resume_early(), or > > ->resume() callbacks. > > Up to here, this sounds great. > > > Instead, it will invoke ->runtime_resume() during the device resume > > stage of system resume. > > But this part I'm not fully following... You're not looking at the most recent one. :-) Please look here: https://patchwork.kernel.org/patch/4139181/ > > By leaving this flag set after ->suspend(), 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. > > But taking this "leave runtime suspended" idea the next logical step, > why would/should a device need to return to full power at the ->resume() > stage? especially when it wasn't at full power when ->suspend() > happened? Good question and I've been thinking about that for a while. Generally, the main reason for resuming is that on some platforms devices are automatically powered up by firmware and in those cases it's better to resume them (to make the runtime PM status reflect the physical state) and suspend again later. Generally speaking, subsystems that need to do that know what they are and that's what I was talking about in the most recent reply to Alan: http://marc.info/?l=linux-pm&m=139967477806094&w=4 Currently, I think, there are two options on the table really. 1. Do more or less what https://patchwork.kernel.org/patch/4139181/ does with a modification to check that ->suspend() doesn't "cheat" (by setting the flag that had been unset before it was called). The subsystem's ->resume() would then decide what to do with the device (resume it or leave it suspended). 2. Do what Alan was suggesting, that is set the flag in ->prepare() and make the PM core skip *all* of the system suspend/resume callbacks for devices with that flag set and let the ->complete() callback decide what to do with the device. I'm leaning a bit towards 2, but still considering 1 too. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
