From: Kevin Hilman <khilman@linaro.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
"linux-pm\@vger.kernel.org" <linux-pm@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux PCI <linux-pci@vger.kernel.org>,
<linux-usb@vger.kernel.org>
Subject: Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend
Date: Tue, 19 Nov 2013 08:45:13 -0800 [thread overview]
Message-ID: <87r4acmjc6.fsf@linaro.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1311191011470.1145-100000@iolanthe.rowland.org> (Alan Stern's message of "Tue, 19 Nov 2013 10:35:46 -0500 (EST)")
Alan Stern <stern@rowland.harvard.edu> writes:
> On Tue, 19 Nov 2013, Ulf Hansson wrote:
>
>> At the moment, system PM is already affecting behaviour of runtime PM
>> since it is preventing runtime suspend during system suspend.
>
> Sure. And that behavior is documented. In any case, it's a bug for
> drivers to depend on runtime suspend for carrying out a system suspend.
As Rafael mentioned, there is bus/pm_domain code that comes into play
here, so I'm not sure it's always a bug.
IMO, it's not a bug for the driver to depend on runtime PM if the
bus/pm_domain is handling the details.
On OMAP, we handle all the SoC on-chip devices with a pm_domain since
the low-level PM operations that need to happen are bus-level things not
device-level things. Therefore, drivers for these devices can rely
entirely on runtime PM, even for system suspend. The late/early
callbacks in the pm_domain can see if the device is runtime suspended
already or not and behave accordingly.
So, this all *can* work by handling it at the bus/pm_domain level, but
as Ulf has mentioned (and I agree) it seems like a clunky workaround
because the PM core is preventing it from happening as one might expect.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@linaro.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux PCI <linux-pci@vger.kernel.org>,
linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend
Date: Tue, 19 Nov 2013 08:45:13 -0800 [thread overview]
Message-ID: <87r4acmjc6.fsf@linaro.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1311191011470.1145-100000@iolanthe.rowland.org> (Alan Stern's message of "Tue, 19 Nov 2013 10:35:46 -0500 (EST)")
Alan Stern <stern@rowland.harvard.edu> writes:
> On Tue, 19 Nov 2013, Ulf Hansson wrote:
>
>> At the moment, system PM is already affecting behaviour of runtime PM
>> since it is preventing runtime suspend during system suspend.
>
> Sure. And that behavior is documented. In any case, it's a bug for
> drivers to depend on runtime suspend for carrying out a system suspend.
As Rafael mentioned, there is bus/pm_domain code that comes into play
here, so I'm not sure it's always a bug.
IMO, it's not a bug for the driver to depend on runtime PM if the
bus/pm_domain is handling the details.
On OMAP, we handle all the SoC on-chip devices with a pm_domain since
the low-level PM operations that need to happen are bus-level things not
device-level things. Therefore, drivers for these devices can rely
entirely on runtime PM, even for system suspend. The late/early
callbacks in the pm_domain can see if the device is runtime suspended
already or not and behave accordingly.
So, this all *can* work by handling it at the bus/pm_domain level, but
as Ulf has mentioned (and I agree) it seems like a clunky workaround
because the PM core is preventing it from happening as one might expect.
Kevin
next prev parent reply other threads:[~2013-11-19 16:45 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 16:29 [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend Ulf Hansson
2013-11-13 19:16 ` Alan Stern
2013-11-13 19:16 ` Alan Stern
2013-11-13 22:21 ` Rafael J. Wysocki
2013-11-14 13:21 ` Ulf Hansson
2013-11-14 15:59 ` Alan Stern
2013-11-14 15:59 ` Alan Stern
2013-11-14 16:40 ` Ulf Hansson
2013-11-14 17:57 ` Alan Stern
2013-11-14 17:57 ` Alan Stern
2013-11-15 8:44 ` Ulf Hansson
2013-11-15 9:29 ` Bjørn Mork
2013-11-15 9:29 ` Bjørn Mork
2013-11-15 10:34 ` Ulf Hansson
2013-11-15 15:22 ` Alan Stern
2013-11-15 15:22 ` Alan Stern
2013-11-18 13:27 ` Ulf Hansson
2013-11-18 15:17 ` Alan Stern
2013-11-18 15:17 ` Alan Stern
2013-11-19 12:21 ` Ulf Hansson
2013-11-19 13:21 ` Rafael J. Wysocki
2013-11-19 15:35 ` Alan Stern
2013-11-19 15:35 ` Alan Stern
2013-11-19 16:45 ` Kevin Hilman [this message]
2013-11-19 16:45 ` Kevin Hilman
2013-11-19 18:03 ` Alan Stern
2013-11-19 18:03 ` Alan Stern
2013-11-19 18:43 ` Kevin Hilman
2013-11-19 18:43 ` Kevin Hilman
2013-11-21 9:00 ` Ulf Hansson
2013-11-21 9:00 ` Ulf Hansson
2013-11-21 15:54 ` Alan Stern
2013-11-21 15:54 ` Alan Stern
2013-11-22 8:19 ` Ulf Hansson
2013-11-22 12:06 ` Rafael J. Wysocki
2013-11-20 10:52 ` Ulf Hansson
2013-11-20 11:23 ` Pavel Machek
2013-11-20 11:53 ` Rafael J. Wysocki
2013-11-20 12:43 ` Ulf Hansson
2013-11-20 16:58 ` Alan Stern
2013-11-20 16:58 ` Alan Stern
2013-11-20 19:55 ` Pavel Machek
2013-11-20 16:55 ` Alan Stern
2013-11-20 16:55 ` Alan Stern
2013-11-13 22:13 ` Rafael J. Wysocki
2013-11-14 14:32 ` Ulf Hansson
2013-11-14 14:32 ` Ulf Hansson
2013-11-14 15:55 ` Alan Stern
2013-11-14 15:55 ` Alan Stern
2013-11-21 9:11 ` Ulf Hansson
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=87r4acmjc6.fsf@linaro.org \
--to=khilman@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=len.brown@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
--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.