From: khilman@kernel•org (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain
Date: Mon, 15 Jun 2015 11:43:53 -0700 [thread overview]
Message-ID: <7hioao6cd2.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20150611145649.GC1103@linaro.org> (Lina Iyer's message of "Thu, 11 Jun 2015 08:56:49 -0600")
Lina Iyer <lina.iyer@linaro•org> writes:
> On Wed, Jun 10 2015 at 15:38 -0600, Kevin Hilman wrote:
>>Lina Iyer <lina.iyer@linaro•org> writes:
>>
>>> Generally cpus are grouped under a power domain in a SoC. When all cpus
>>> in the domain are in their power off state, the cpu domain can also be
>>> powered off.
>>
>>How does this relate to a cluster, and why aren't you using that terminolgy?
>>
>>> Genpd provides the framework for defining cpus as devices
>>> that are part of a cpu domain.
>>>
>>> Introduce support for defining and adding a generic power domain for the
>>> cpus based on the DT specification of power domain providers and
>>> consumers. SoC's that have the cpu domain defined in their DT, can
>>> setup a genpd with a name and the power_on/power_off callbacks. Calling
>>> pm_cpu_domain_init() will register the genpd and attach the cpus for
>>> this domain with the genpd.
>>>
>>> CPU_PM notifications for are used to pm_runtime_get_sync() and
>>> pm_runtime_put_sync() for each cpu. When all cpus are powered off, the
>>> last cpu going down would call the genpd->power_off(). Correspondingly,
>>> the first cpu up would call the genpd->power_on() callback before
>>> resuming from idle.
>>
>>Other patches also mention this genpd being useful to gate power to
>>non-CPU peripherals on the same power rail. How are those devices to be
>>added?
>>
> I am not investigating DT nodes to figure out which node is a consumer
> for this domain provider. That could be a good way to do it, but
> practically speaking, there may be platform dependencies and specifics
> that may need to be met, before the device can be added to the CPU
> genpd.
>
> So that is not generalized here. I didn't see a better way to do that,
> generically. Do you have ideas on that?
>
> The platform is the owner of the genpd and therefore can add those
> non-cpu devices to the genpd as and when appropritate.
I'm pretty sure the generic code will already add devices to genpds if
the genpd is using the of_genpd_* stuff. That is why I'm wondering why
the extra stuff for CPUs is needed.
> In this regard, I also have a question, who initializes the genpd. My
> assumption is that CPUs will get probed before most other devices and
> therefore the domain provider could be initialized by this file. But, I
> could be wrong here.
Initializing it in this driver seems OK to me.
Kevin
next prev parent reply other threads:[~2015-06-15 18:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 22:29 [PATCH RFC 0/3] PM / Domains: Generic PM domains for cpus Lina Iyer
2015-06-04 22:29 ` [PATCH RFC 1/3] PM / Domains: Allocate memory outside domain locks Lina Iyer
2015-06-07 8:35 ` Krzysztof Kozlowski
2015-06-09 22:45 ` Lina Iyer
2015-06-10 17:33 ` Kevin Hilman
2015-06-04 22:29 ` [PATCH RFC 2/3] PM / Domains: Support atomic PM domains Lina Iyer
2015-06-07 9:21 ` Krzysztof Kozlowski
2015-06-10 16:13 ` Lina Iyer
2015-06-11 0:13 ` Krzysztof Kozlowski
2015-06-11 14:33 ` Lina Iyer
2015-06-10 18:04 ` Kevin Hilman
2015-06-10 20:35 ` Lina Iyer
2015-06-11 9:41 ` Ulf Hansson
2015-06-11 19:47 ` Lina Iyer
2015-06-11 21:13 ` Ulf Hansson
2015-06-04 22:29 ` [PATCH RFC 3/3] PM / Domains: Introduce generic PM domain for cpu domain Lina Iyer
2015-06-07 9:42 ` Krzysztof Kozlowski
2015-06-10 16:57 ` Lina Iyer
2015-06-11 0:27 ` Krzysztof Kozlowski
2015-06-11 14:42 ` Lina Iyer
2015-06-10 17:01 ` Kevin Hilman
2015-06-11 0:35 ` Krzysztof Kozlowski
2015-06-10 21:37 ` Kevin Hilman
2015-06-11 14:56 ` Lina Iyer
2015-06-15 18:43 ` Kevin Hilman [this message]
2015-06-15 19:14 ` Lina Iyer
2015-06-16 15:50 ` Kevin Hilman
2015-06-10 17:24 ` [PATCH RFC 0/3] PM / Domains: Generic PM domains for cpus Kevin Hilman
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=7hioao6cd2.fsf@deeprootsystems.com \
--to=khilman@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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