ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions
Date: Thu, 19 Oct 2017 10:55:42 +0200	[thread overview]
Message-ID: <CAPDyKFqFDH7kupxkQfEm9jMuGvOC1Nt2s7ydG2Xp78R8Y_NVdA@mail.gmail.com> (raw)
In-Reply-To: <1647817.aU4A16bmHW@aspire.rjw.lan>

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

  reply	other threads:[~2017-10-19  8:55 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 [this message]
2017-10-21 10:56 ` Linus Walleij
2017-10-21 23:36   ` Rafael J. Wysocki
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=CAPDyKFqFDH7kupxkQfEm9jMuGvOC1Nt2s7ydG2Xp78R8Y_NVdA@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=rjw@rjwysocki.net \
    /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