On 16 October 2017 at 03:29, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > Define and document a SMART_SUSPEND flag to instruct bus types and PM > domains that the system suspend callbacks provided by the driver can > cope with runtime-suspended devices, so from the driver's perspective > it should be safe to leave devices in runtime suspend during system > suspend. > > Setting that flag also causes the PM core to skip the "late" and > "noirq" phases of device suspend for devices that remain in runtime > suspend at the beginning of the "late" phase (when runtime PM has > been disabled for them) under the assumption that their state cannot > (and should not) change after that point until the system suspend > transition is complete. Moreover, the PM core prevents runtime PM > from acting on devices with DPM_FLAG_SMART_SUSPEND during system > resume by setting their runtime PM status to "active" at the end of > the "early" phase (right prior to enabling runtime PM for them). > That allows system resume callbacks to do whatever is necessary to > resume the device without worrying about runtime PM possibly > running in parallel with them. After some sleep, I woke up and realized that the hole thing of making the PM core skip invoking system sleep callbacks, is not compatible with devices being attached to the genpd. Sorry. The reason is because genpd may not power off the PM domain, even if all devices attached to it are runtime suspended. For example, due to a subdomain holding it powered or because a PM QoS constraints prevents to power off it in runtime. Then to understand whether it shall power off/on the PM domain, during system-wide PM it requires the system sleep callbacks to be invoked. So, even if the driver can cope with the behavior from DPM_FLAG_SMART_SUSPEND, then what happens when the PM domain (genpd) can not? Taking this into account, this feels like solution entirely specific to ACPI and PCI. That is fine by me, however then we still have those cross SoC drivers, the i2c-designware driver, which may have its device attached to an ACPI PM domain or perhaps a genpd. > > However, that doesn't apply to transitions involving ->thaw_noirq, > ->thaw_early and ->thaw callbacks during hibernation, as they > generally are not expected to change the power states of devices. > Consequently, if a device is in runtime suspend at the beginning > of such a transition, it must stay in runtime suspend until the > "complete" phase of it (since the callbacks may not change its > power state). > [...] Kind regards Uffe
