From: Kevin Hilman <khilman@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
linux-pm@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes
Date: Mon, 17 Nov 2014 10:28:56 -0800 [thread overview]
Message-ID: <7hd28l3clz.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1416237550-31092-1-git-send-email-ulf.hansson@linaro.org> (Ulf Hansson's message of "Mon, 17 Nov 2014 16:19:10 +0100")
Ulf Hansson <ulf.hansson@linaro.org> writes:
> The amba bus, amba drivers and a vast amount of platform drivers which
> enables runtime PM, don't invoke a pm_runtime_get_sync() while probing
> their devices.
>
> Instead, once they have turned on their PM resourses during ->probe()
> and are ready to handle I/O, these invokes pm_runtime_set_active() to
> synchronize its state towards the runtime PM core.
>
> From a runtime PM point of view this behavior is perfectly acceptable,
In the context of PM domains that can be dynamically powered on/off, I'm
not so sure it's perfectly acceptable anymore.
Why doesn't the bus do a _get_sync() instead of a _get_noresume()
followed by a _set_active().
By using the _get_noresume() you're bypassing the paths that would bring
up your PM domain.
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@kernel.org (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PM / Domains: Power on the PM domain right after attach completes
Date: Mon, 17 Nov 2014 10:28:56 -0800 [thread overview]
Message-ID: <7hd28l3clz.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1416237550-31092-1-git-send-email-ulf.hansson@linaro.org> (Ulf Hansson's message of "Mon, 17 Nov 2014 16:19:10 +0100")
Ulf Hansson <ulf.hansson@linaro.org> writes:
> The amba bus, amba drivers and a vast amount of platform drivers which
> enables runtime PM, don't invoke a pm_runtime_get_sync() while probing
> their devices.
>
> Instead, once they have turned on their PM resourses during ->probe()
> and are ready to handle I/O, these invokes pm_runtime_set_active() to
> synchronize its state towards the runtime PM core.
>
> From a runtime PM point of view this behavior is perfectly acceptable,
In the context of PM domains that can be dynamically powered on/off, I'm
not so sure it's perfectly acceptable anymore.
Why doesn't the bus do a _get_sync() instead of a _get_noresume()
followed by a _set_active().
By using the _get_noresume() you're bypassing the paths that would bring
up your PM domain.
Kevin
next prev parent reply other threads:[~2014-11-17 18:28 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 15:19 [PATCH] PM / Domains: Power on the PM domain right after attach completes Ulf Hansson
2014-11-17 15:19 ` Ulf Hansson
2014-11-17 15:32 ` Russell King - ARM Linux
2014-11-17 15:32 ` Russell King - ARM Linux
2014-11-17 16:54 ` Grygorii Strashko
2014-11-17 16:54 ` Grygorii Strashko
2014-11-17 17:07 ` Russell King - ARM Linux
2014-11-17 17:07 ` Russell King - ARM Linux
2014-11-17 18:28 ` Kevin Hilman [this message]
2014-11-17 18:28 ` Kevin Hilman
2014-11-17 19:06 ` Alan Stern
2014-11-17 19:06 ` Alan Stern
2014-11-17 19:17 ` Dmitry Torokhov
2014-11-17 19:17 ` Dmitry Torokhov
2014-11-17 19:54 ` Alan Stern
2014-11-17 19:54 ` Alan Stern
2014-11-17 20:28 ` Dmitry Torokhov
2014-11-17 20:28 ` Dmitry Torokhov
2014-11-17 20:49 ` Alan Stern
2014-11-17 20:49 ` Alan Stern
2014-11-17 21:11 ` Dmitry Torokhov
2014-11-17 21:11 ` Dmitry Torokhov
2014-11-17 21:44 ` Alan Stern
2014-11-17 21:44 ` Alan Stern
2014-11-17 22:02 ` Dmitry Torokhov
2014-11-17 22:02 ` Dmitry Torokhov
2014-11-17 22:12 ` Alan Stern
2014-11-17 22:12 ` Alan Stern
2014-11-17 22:17 ` Dmitry Torokhov
2014-11-17 22:17 ` Dmitry Torokhov
2014-11-17 23:28 ` Rafael J. Wysocki
2014-11-17 23:28 ` Rafael J. Wysocki
2014-11-17 23:26 ` Dmitry Torokhov
2014-11-17 23:26 ` Dmitry Torokhov
2014-11-18 0:26 ` Rafael J. Wysocki
2014-11-18 0:26 ` Rafael J. Wysocki
2014-11-18 2:16 ` Rafael J. Wysocki
2014-11-18 2:16 ` Rafael J. Wysocki
2014-11-18 14:05 ` Ulf Hansson
2014-11-18 14:05 ` Ulf Hansson
2014-11-18 20:29 ` Rafael J. Wysocki
2014-11-18 20:29 ` Rafael J. Wysocki
2014-11-19 8:54 ` Ulf Hansson
2014-11-19 8:54 ` Ulf Hansson
2014-11-20 0:35 ` Rafael J. Wysocki
2014-11-20 0:35 ` Rafael J. Wysocki
2014-11-20 10:13 ` Ulf Hansson
2014-11-20 10:13 ` Ulf Hansson
2014-11-20 20:56 ` Rafael J. Wysocki
2014-11-20 20:56 ` Rafael J. Wysocki
2014-11-20 12:17 ` Grygorii Strashko
2014-11-20 12:17 ` Grygorii Strashko
2014-11-20 13:01 ` Ulf Hansson
2014-11-20 13:01 ` Ulf Hansson
2014-11-20 15:06 ` Grygorii Strashko
2014-11-20 15:06 ` Grygorii Strashko
2014-11-18 16:13 ` Alan Stern
2014-11-18 16:13 ` Alan Stern
2014-11-18 17:18 ` Dmitry Torokhov
2014-11-18 17:18 ` Dmitry Torokhov
2014-11-18 17:44 ` Alan Stern
2014-11-18 17:44 ` Alan Stern
2014-11-18 17:55 ` Dmitry Torokhov
2014-11-18 17:55 ` Dmitry Torokhov
2014-11-18 20:14 ` Rafael J. Wysocki
2014-11-18 20:14 ` Rafael J. Wysocki
2014-11-18 20:04 ` Dmitry Torokhov
2014-11-18 20:04 ` Dmitry Torokhov
2014-11-18 21:03 ` Rafael J. Wysocki
2014-11-18 21:03 ` Rafael J. Wysocki
2014-11-18 21:17 ` Rafael J. Wysocki
2014-11-18 21:17 ` Rafael J. Wysocki
2014-11-18 21:02 ` Dmitry Torokhov
2014-11-18 21:02 ` Dmitry Torokhov
2014-11-18 21:58 ` Rafael J. Wysocki
2014-11-18 21:58 ` Rafael J. Wysocki
2014-11-18 21:44 ` Dmitry Torokhov
2014-11-18 21:44 ` Dmitry Torokhov
2014-11-18 22:10 ` Rafael J. Wysocki
2014-11-18 22:10 ` 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=7hd28l3clz.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=s.nawrocki@samsung.com \
--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.