From: Rajendra Nayak <rnayak@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Rafael Wysocki <rjw@rjwysocki.net>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Boyd <sboyd@codeaurora.org>,
Nishanth Menon <nm@ti.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Kevin Hilman <khilman@baylibre.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Lina Iyer <lina.iyer@linaro.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
Date: Fri, 06 Jan 2017 14:16:36 +0530 [thread overview]
Message-ID: <586F596C.7000807@codeaurora.org> (raw)
In-Reply-To: <dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar@linaro.org>
On 12/12/2016 04:26 PM, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> The power-domains until now were only concentrating on the idle state
> management of the device and this needs to change in order to reuse the
> infrastructure of power domains for active state management.
>
> This patch adds binding to describe the performance states of a power
> domain.
The bindings would also need to take into account the fact that a device
could (and is quite often the case with qcom platforms) have 2 separate
powerdomains, one for idle state management and another to manage active
states. I guess the below bindings assume that there's just one.
- Rajendra
>
> If the consumers don't need the capability of switching to different
> domain performance states at runtime, then they can simply define their
> required domain performance state in their node directly. Otherwise the
> consumers can define their requirements with help of other
> infrastructure, for example the OPP table.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/power/power_domain.txt | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..a456e0dc04e0 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -38,6 +38,40 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> domain's idle states. In the absence of this property, the domain would be
> considered as capable of being powered-on or powered-off.
>
> +- domain-performance-states : A phandle of the performance states node, which
> + defines all the performance states associated with a power
> + domain.
> + The domain-performance-states property reflects the performance states of this
> + PM domain and not the performance states of the devices or sub-domains in the
> + PM domain. Devices and sub-domains have their own performance states, which
> + are dependent on the performance state of the PM domain.
> +
> +* PM domain performance states node
> +
> +This describes the performance states of a PM domain.
> +
> +Required properties:
> +- compatible: Allow performance states to express their compatibility. It should
> + be: "domain-performance-state".
> +
> +- Performance state nodes: This node shall have one or more "Performance State"
> + nodes.
> +
> +* Performance state node
> +
> +Required properties:
> +- performance-level: A positive integer value representing the performance level
> + associated with a performance state. The integer value '1' represents the
> + lowest performance level and the highest value represents the highest
> + performance level.
> +
> +Optional properties:
> +- domain-microvolt: voltage in micro Volts.
> +
> + A single regulator's voltage is specified with an array of size one or three.
> + Single entry is for target voltage and three entries are for <target min max>
> + voltages.
> +
> Example:
>
> power: power-controller@12340000 {
> @@ -118,4 +152,39 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- domain-performance-state: A phandle of a Performance state node.
> +
> +Example:
> +
> + parent: power-controller@12340000 {
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <0>;
> + domain-performance-states = <&domain_perf_states>;
> + };
> +
> + domain_perf_states: performance_states {
> + compatible = "domain-performance-state";
> + domain_perf_state1: pstate@1 {
> + performance-level = <1>;
> + domain-microvolt = <970000 975000 985000>;
> + };
> + domain_perf_state2: pstate@2 {
> + performance-level = <2>;
> + domain-microvolt = <1000000 1075000 1085000>;
> + };
> + domain_perf_state3: pstate@3 {
> + performance-level = <3>;
> + domain-microvolt = <1100000 1175000 1185000>;
> + };
> + }
> +
> + leaky-device@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&power 0>;
> + domain-performance-state = <&domain_perf_state2>;
> + };
> +
> [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2017-01-06 8:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 10:56 [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding Viresh Kumar
2016-12-12 10:56 ` [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding Viresh Kumar
[not found] ` <dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-12-22 18:34 ` Rob Herring
2017-01-02 10:05 ` Viresh Kumar
2017-01-06 8:46 ` Rajendra Nayak [this message]
[not found] ` <586F596C.7000807-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-01-06 9:27 ` Viresh Kumar
2017-01-06 10:12 ` Rajendra Nayak
2017-01-06 10:23 ` Viresh Kumar
2017-01-06 10:36 ` Rajendra Nayak
2017-01-06 11:09 ` Viresh Kumar
2016-12-12 10:56 ` [PATCH V2 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes Viresh Kumar
2016-12-22 18:14 ` [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding Rob Herring
2017-01-02 10:44 ` Viresh Kumar
2017-01-03 11:07 ` Viresh Kumar
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=586F596C.7000807@codeaurora.org \
--to=rnayak@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=khilman@baylibre.com \
--cc=lina.iyer@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=ulf.hansson@linaro.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).