ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions
Date: Sun, 22 Oct 2017 01:36:03 +0200	[thread overview]
Message-ID: <2932433.MBmHVLMLTR@aspire.rjw.lan> (raw)
In-Reply-To: <CACRpkdYuAduT1oH=+2gLjdP2_805PO5Ubpu6XY5B=mz9gU1BMQ@mail.gmail.com>

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

  reply	other threads:[~2017-10-21 23:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 11:17 Rafael J. Wysocki
2017-10-19  8:55 ` Ulf Hansson
2017-10-21 10:56 ` Linus Walleij
2017-10-21 23:36   ` Rafael J. Wysocki [this message]
2017-10-21 18:51 ` Bart Van Assche
2017-10-21 23:41   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2932433.MBmHVLMLTR@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox