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

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

[Rafael J. Wysocki]

Hi,

If this isn't too late, I'd like to put a PM topic on the agenda.

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?

We have tried to address these points in a couple of different ways so
far, but none of them is universal enough.  Moreover, one approach is
mostly for systems with PCI/ACPI and the other one is used on systems
without those and they both are not compatible.  That sort of didn't
matter until IP block sharing between vendors led to situations in
which one and the same driver is expected to work in both environments.

It would be good to have a common approach and IMO it should be based on
changing the PM core to help address the most common cases, so I posted
a set of patches to that end:

https://marc.info/?l=linux-kernel&m=150811822405206&w=2

and I'd like to have a discussion regarding that and it spans many
different subsystems potentially, so the KS seems to be the right venue
for that discussion to happen.

The second issue is that some bus types and quite a few drivers still use
legacy power management callbacks and I'd like to get rid of those at last,
first from the bus types and then from drivers too.  That's more of a
heads-up thing, but also possibly touches multiple places, so should be
suitable for a KS session as well.

Thanks,
Rafael

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

[Ulf Hansson]

On 18 October 2017 at 13:17, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> Hi,
>
> If this isn't too late, I'd like to put a PM topic on the agenda.
>
> 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?
>
> We have tried to address these points in a couple of different ways so
> far, but none of them is universal enough.  Moreover, one approach is
> mostly for systems with PCI/ACPI and the other one is used on systems
> without those and they both are not compatible.  That sort of didn't
> matter until IP block sharing between vendors led to situations in
> which one and the same driver is expected to work in both environments.
>
> It would be good to have a common approach and IMO it should be based on
> changing the PM core to help address the most common cases, so I posted
> a set of patches to that end:
>
> https://marc.info/?l=linux-kernel&m=150811822405206&w=2
>
> and I'd like to have a discussion regarding that and it spans many
> different subsystems potentially, so the KS seems to be the right venue
> for that discussion to happen.
>
> The second issue is that some bus types and quite a few drivers still use
> legacy power management callbacks and I'd like to get rid of those at last,
> first from the bus types and then from drivers too.  That's more of a
> heads-up thing, but also possibly touches multiple places, so should be
> suitable for a KS session as well.
>
> Thanks,
> Rafael
>

Rafael, thanks for suggesting this topic, of course I share your
interest in discussion this in Prague.

Kind regards
Uffe

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

[Linus Walleij]

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

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

[Bart Van Assche]

On Wed, 2017-10-18 at 13:17 +0200, Rafael J. Wysocki wrote:
> If this isn't too late, I'd like to put a PM topic on the agenda.
> 
> 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?
> 
> We have tried to address these points in a couple of different ways so
> far, but none of them is universal enough.  Moreover, one approach is
> mostly for systems with PCI/ACPI and the other one is used on systems
> without those and they both are not compatible.  That sort of didn't
> matter until IP block sharing between vendors led to situations in
> which one and the same driver is expected to work in both environments.
> 
> It would be good to have a common approach and IMO it should be based on
> changing the PM core to help address the most common cases, so I posted
> a set of patches to that end:
> 
> https://marc.info/?l=linux-kernel&m=150811822405206&w=2
> 
> and I'd like to have a discussion regarding that and it spans many
> different subsystems potentially, so the KS seems to be the right venue
> for that discussion to happen.
> 
> The second issue is that some bus types and quite a few drivers still use
> legacy power management callbacks and I'd like to get rid of those at last,
> first from the bus types and then from drivers too.  That's more of a
> heads-up thing, but also possibly touches multiple places, so should be
> suitable for a KS session as well.

Hello Rafael,

How about adding orderly freezing of the storage stack to the list of items
to discuss? Some people use the md RAID1 driver on their laptop and run a
filesystem on top of the md RAID1 driver. Both the XFS filesystem and the md
RAID1 driver create kernel threads. Freezing of kernel threads does not yet
happen in a top-down order compared to the order in which storage drivers
and filesystems have been stacked. Do you think this should be discussed
during the KS time slot about PM?

For a related discussion, see also Luis R. Rodriguez, [RFC 0/5] fs: replace
kthread freezing with filesystem freeze/thaw, 3 October 2017
(https://lkml.org/lkml/2017/10/3/821).

Thanks,

Bart.

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

[Rafael J. Wysocki]

On Saturday, October 21, 2017 12:56:05 PM CEST Linus Walleij wrote:
> 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.

The force* callbacks are not suitable for all cases, though.

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

Well, not exactly, but there is quite a bit of that.

Basically it boils down to whether or not middle layer code is involved in PM
and what exactly is does (or expects to be done) and whether or not devices are
allowed to wake up the system from sleep.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Saturday, October 21, 2017 8:51:41 PM CEST Bart Van Assche wrote:
> On Wed, 2017-10-18 at 13:17 +0200, Rafael J. Wysocki wrote:
> > If this isn't too late, I'd like to put a PM topic on the agenda.
> > 
> > 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?
> > 
> > We have tried to address these points in a couple of different ways so
> > far, but none of them is universal enough.  Moreover, one approach is
> > mostly for systems with PCI/ACPI and the other one is used on systems
> > without those and they both are not compatible.  That sort of didn't
> > matter until IP block sharing between vendors led to situations in
> > which one and the same driver is expected to work in both environments.
> > 
> > It would be good to have a common approach and IMO it should be based on
> > changing the PM core to help address the most common cases, so I posted
> > a set of patches to that end:
> > 
> > https://marc.info/?l=linux-kernel&m=150811822405206&w=2
> > 
> > and I'd like to have a discussion regarding that and it spans many
> > different subsystems potentially, so the KS seems to be the right venue
> > for that discussion to happen.
> > 
> > The second issue is that some bus types and quite a few drivers still use
> > legacy power management callbacks and I'd like to get rid of those at last,
> > first from the bus types and then from drivers too.  That's more of a
> > heads-up thing, but also possibly touches multiple places, so should be
> > suitable for a KS session as well.
> 
> Hello Rafael,
> 
> How about adding orderly freezing of the storage stack to the list of items
> to discuss?

Do you mean add it to the agenda?

We can do that I think, but then I'm not sure how much time we'll be able to
spend on it.

> Some people use the md RAID1 driver on their laptop and run a
> filesystem on top of the md RAID1 driver. Both the XFS filesystem and the md
> RAID1 driver create kernel threads. Freezing of kernel threads does not yet
> happen in a top-down order compared to the order in which storage drivers
> and filesystems have been stacked. Do you think this should be discussed
> during the KS time slot about PM?

Well, it should be discussed and the PM session would be a good opportunity
for at least some discussio about that to happen IMO.

> For a related discussion, see also Luis R. Rodriguez, [RFC 0/5] fs: replace
> kthread freezing with filesystem freeze/thaw, 3 October 2017
> (https://lkml.org/lkml/2017/10/3/821).

Yup.

Thanks,
Rafael