On 6 September 2017 at 12:46, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > On Wednesday, September 6, 2017 2:52:59 AM CEST Rafael J. Wysocki wrote: >> On Monday, September 4, 2017 2:55:37 PM CEST Ulf Hansson wrote: >> > [...] > > I guess I can wrap it up, because all of the points seem to have been stated > and repeating them would not be useful. > > My summary of the discussion is as follows. > > It only is valid to use pm_runtime_force_suspend/resume() as *driver* > callbacks for system suspend/resume if both the driver itself and all of > the middle layers it has to work with carry out the same sequence of > operations in order to suspend the device both in runtime PM and for > system sleep (and analogously for resuming). [The middle layers need > to meet additional conditions, but that's less relevant.] > > Unfortunately, for the ACPI PM domain and the PCI bus type the situation is > different, because they generally need to do different things to suspend > devices for system sleep than they do for runtime PM (which mostly is > related to the handling of ACPI-defined sleep states and device/system > wakeup, but not limited to that). This clearly means that drivers needing > to work with the ACPI PM domain and PCI drivers cannot use > pm_runtime_force_suspend/resume() as their PM callbacks for system > suspend/resume (quite fundamentally). > > [Note that for i2c-designware-platdrv the situation is even more complicated, > because on some platforms it has to work with the ACPI PM domain (or the > ACPI LPSS driver), on some platforms its parent is a PCI device and on > some other platforms there's none of them.] That is also why it makes it really interesting. I am guessing we will be seeing more of these cases sooner or later. To make it even more complex, I can guess we can expect cases when genpd is mixed with the ACPI PM domain. > > However, for drivers that need to work with the ACPI PM domain and > PCI drivers the differences in the device handling between runtime PM and > system suspend/resume are *very* often (even though not always) covered > entirely by the middle layer code. Then, the driver itself actually > always carries out the same sequence of operations in order to suspend > the device (or to resume it, analogously). The driver then can re-use > its runtime PM callbacks for system suspend/resume (but at the driver > level only) and it would be good to make that easy (or easier) for these > drivers somehow. This is a very nice summary so far, thanks for putting it together. Kind regards Uffe -- 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
