[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0hvCuJbt8wtCJFcLRpCdkNu=vGEuA7_dCWhkXgvGxgizw@mail.gmail.com>
Date: Tue, 2 Jan 2018 12:21:43 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: Linux PM <linux-pm@...r.kernel.org>,
Kevin Hilman <khilman@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] PM / runtime: Rework pm_runtime_force_suspend/resume()
On Tue, Jan 2, 2018 at 12:02 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Tue, Jan 2, 2018 at 11:51 AM, Lukas Wunner <lukas@...ner.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
Powered by blists - more mailing lists