Re: [Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, Oct 18, 2017 at 1:17 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> One problem basically is that runtime PM interacts with system-wide PM for
> devices in ways that need to be taken care of.  The most common patterns are:
>
> - What if a device is in runtime suspend before system suspend?  Can it
>   remain suspended and under what conditions if so?
>
> - Can devices be left in suspend when the system is resuming from
>   system-wide suspend?
>
> - Can driver runtime PM callbacks be used for system-wide PM too and to
>   what extent?  If they can, how to make that happen?

These are very important topics for PM.

Maybe more of an ELC workshop than KS though?

A while back I augmented I2C and SPI to use runtime PM and we achived
nice PM on such off-chip devices for case (1) and (3) above using the
force* callbacks.

Examples:
commit 04f59143b571161d25315dd52d7a2ecc022cb71a
"i2c: let I2C masters ignore their children for PM"
commit d7e2ee257038baeb03baef602500368a51ee9eef
"spi: let SPI masters ignore their children for PM"
commit 9a9a369d6178dd4e263c49085ce1b37e1e8f63a0
"iio: accel: kxsd9: Deploy system and runtime PM"

So in I2C or SPI runtime PM is reused for suspending, and resuming,
if the device is already in suspend, it just remains suspended in system-wide
sleep.

I didn't achive (2), so slow peripheral bus devices still resume when
the system (main chip/bridges) resume. Then after a while it puts itself to
runtime sleep again. Which is not optimal and a bit annoying.

I won't be in Prague, but the SPI and I2C maintainers may be
so paging them.

>From my standpoint it looks like a conflict between firmware-oriented
(such as ACPI, proper OpenFirmware (not just device tree), SFI etc)
design paradigm and full kernel control of peripheral power states.
The two camps need to understand each other.

Yours,
Linus Walleij