From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "gregkh@linuxfoundation.org" <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: Sun, 22 Oct 2017 01:41:00 +0200 [thread overview]
Message-ID: <5637947.KstaCg8mCx@aspire.rjw.lan> (raw)
In-Reply-To: <1508611900.9251.17.camel@wdc.com>
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
prev parent reply other threads:[~2017-10-21 23:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-18 11:17 [Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions 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
2017-10-21 18:51 ` Bart Van Assche
2017-10-21 23:41 ` Rafael J. Wysocki [this message]
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=5637947.KstaCg8mCx@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=Bart.VanAssche@wdc.com \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).