All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] PM / runtime: Rework pm_runtime_force_suspend/resume()
Date: Tue, 2 Jan 2018 12:21:43 +0100	[thread overview]
Message-ID: <CAJZ5v0hvCuJbt8wtCJFcLRpCdkNu=vGEuA7_dCWhkXgvGxgizw@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0hYaEWPhqEuBkj7yusQiY1wfeJAn7QDfp-gmOYyNXatEg@mail.gmail.com>

On Tue, Jan 2, 2018 at 12:02 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Tue, Jan 2, 2018 at 11:51 AM, Lukas Wunner <lukas@wunner.de> wrote:
>> On Tue, Jan 02, 2018 at 01:56:28AM +0100, Rafael J. Wysocki wrote:

[cut]

>
>> One addition that would be really helpful:  pm_runtime_force_suspend()
>> should also force-suspend all children and consumers of the given
>> device.  Likewise, those should be resumed on pm_runtime_force_resume().
>> Then I could just add a device link from the audio PCI device on the GPU
>> to the graphics PCI device and just call pm_runtime_force_*() on the
>> graphics device (supplier) to magically power them both off and on.
>
> Actually, the assumption is that pm_runtime_force_suspend() must be
> called for the children before it is called for the parent even
> without my patch, so it is just not going to work this way.

Moreover, what if those devices have nonzero usage counters?  There
may be other reasons for that than just dependencies, like for example
user space might have written "on" to their "control" files in sysfs.

What you are looking for doesn't seem to match the runtime PM
framework's assumptions, I'm afraid.

Thanks,
Rafael

  reply	other threads:[~2018-01-02 11:21 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-02  0:56 [PATCH] PM / runtime: Rework pm_runtime_force_suspend/resume() Rafael J. Wysocki
2018-01-02 10:51 ` Lukas Wunner
2018-01-02 11:02   ` Rafael J. Wysocki
2018-01-02 11:21     ` Rafael J. Wysocki [this message]
2018-01-02 13:04     ` Lukas Wunner
2018-01-02 19:07       ` Rafael J. Wysocki
2018-01-02 23:21         ` Rafael J. Wysocki
2018-01-03 11:01           ` Rafael J. Wysocki
2018-01-03 11:06 ` [PATCH v2] " Rafael J. Wysocki
2018-01-09  6:08   ` Ulf Hansson
2018-01-09 12:34     ` Rafael J. Wysocki
2018-01-09 14:13       ` Ulf Hansson
2018-01-12  1:55     ` Rafael J. Wysocki
2018-01-12 13:46       ` Ulf Hansson
2018-01-13  1:23         ` Rafael J. Wysocki
2018-01-09 13:37   ` Geert Uytterhoeven
2018-01-09 14:27     ` Ulf Hansson
2018-01-09 14:34       ` Geert Uytterhoeven
2018-01-09 15:00     ` Rafael J. Wysocki
2018-01-09 15:30       ` Geert Uytterhoeven
2018-01-09 16:03         ` Rafael J. Wysocki
2018-01-09 16:03           ` Rafael J. Wysocki
2018-01-09 16:28           ` Rafael J. Wysocki
2018-01-09 16:28             ` [v2] " Rafael J. Wysocki
2018-01-10  9:26             ` [PATCH v2] " Ulf Hansson
2018-01-10  9:26               ` [v2] " Ulf Hansson
2018-01-11  0:46               ` [PATCH v2] " Rafael J. Wysocki
2018-01-11  0:46                 ` [v2] " Rafael J. Wysocki
2018-01-11 12:32                 ` [PATCH v2] " Ulf Hansson
2018-01-11 12:32                   ` [v2] " Ulf Hansson
2018-01-11 18:44                   ` [PATCH v2] " Rafael J. Wysocki
2018-01-11 18:44                     ` [v2] " Rafael J. Wysocki
2018-01-12 11:26             ` [PATCH v2] " Geert Uytterhoeven
2018-01-12 11:26               ` Geert Uytterhoeven
2018-01-12 11:26               ` [v2] " Geert Uytterhoeven
2018-01-12 12:09               ` [PATCH v2] " Rafael J. Wysocki
2018-01-12 12:09                 ` [v2] " Rafael J. Wysocki
2018-01-09 16:25       ` [PATCH v2] " Rafael J. Wysocki
2018-01-12 11:20         ` Geert Uytterhoeven
2018-01-09 18:46     ` Rafael J. Wysocki
2018-01-09 19:02       ` 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='CAJZ5v0hvCuJbt8wtCJFcLRpCdkNu=vGEuA7_dCWhkXgvGxgizw@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=khilman@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=ulf.hansson@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.