Re: [PATCH v3 0/8] PM / ACPI / i2c: Deploy runtime PM centric path for system sleep

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.]

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.

Thanks,
Rafael




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux