ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Device power management during system-wide PM transitions
Date: Sat, 21 Oct 2017 18:51:41 +0000	[thread overview]
Message-ID: <1508611900.9251.17.camel@wdc.com> (raw)
In-Reply-To: <1647817.aU4A16bmHW@aspire.rjw.lan>

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.

  parent reply	other threads:[~2017-10-21 18:51 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
2017-10-21 18:51 ` Bart Van Assche [this message]
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=1508611900.9251.17.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    --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