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 3:59:16 PM CEST Ulf Hansson wrote:
> 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.

No problem.

I actually have an idea on how to move forward, but let me start a new thread
for discussing that.

Thanks,
Rafael

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



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux