All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	ulf.hansson@linaro.org, Kevin Hilman <khilman@linaro.org>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	lina.iyer@linaro.org, rnayak@codeaurora.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes
Date: Mon, 27 Feb 2017 18:39:48 -0600	[thread overview]
Message-ID: <20170228003948.ihf4c2ppu2rf3lt2@rob-hp-laptop> (raw)
In-Reply-To: <ceb1bf5f696138c30b30743c24b619336d438d7c.1487926924.git.viresh.kumar@linaro.org>

On Fri, Feb 24, 2017 at 02:36:34PM +0530, Viresh Kumar wrote:
> 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 nodes directly.
> 
> But if the device needs the capability of switching to different domain
> performance states, as they may need to support different clock rates,
> then the per OPP node can be used to contain that information.
> 
> This patch introduces the domain-performance-state (already defined by
> Power Domain bindings) to the per OPP node.
> 

We already have OPP voltages, why are those not sufficient?

> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 64 +++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 9f5ca4457b5f..7f6bb52521b6 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -154,6 +154,15 @@ properties.
>  
>  - status: Marks the node enabled/disabled.
>  
> +- domain-performance-state: A positive integer value representing the minimum
> +  performance level (of the parent domain) required by the consumer as defined
> +  by ../power/power_domain.txt binding document. The OPP nodes can contain the
> +  "domain-performance-state" property, only if the device node contains a
> +  "power-domains" property. The OPP nodes aren't allowed to contain the
> +  "domain-performance-state" property partially, i.e. Either all OPP nodes in
> +  the OPP table have the "domain-performance-state" property or none of them
> +  have it.
> +
>  Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>  
>  / {
> @@ -528,3 +537,58 @@ Example 5: opp-supported-hw
>  		};
>  	};
>  };
> +
> +Example 7: domain-Performance-state:
> +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> +
> +/ {
> +	cpu0_opp_table: opp_table0 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp@1000000000 {
> +			opp-hz = /bits/ 64 <1000000000>;
> +			domain-performance-state = <1>;

Thinking about this some more, there's a problem here that you have no 
link to foo_domain. I guess that resides in the cpu's node?

Perhaps instead of a number, this should be a phandle to pstate@1. Then 
you just get the parent if you need to know the domain.

> +		};
> +		opp@1100000000 {
> +			opp-hz = /bits/ 64 <1100000000>;
> +			domain-performance-state = <2>;
> +		};
> +		opp@1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
> +			domain-performance-state = <2>;
> +		};
> +	};
> +
> +	foo_domain: power-controller@12340000 {
> +		compatible = "foo,power-controller";
> +		reg = <0x12340000 0x1000>;
> +		#power-domain-cells = <0>;
> +
> +		performance-states {
> +			compatible = "domain-performance-state";
> +			pstate@1 {
> +				reg = <1>;
> +				domain-microvolt = <970000 975000 985000>;
> +			};
> +			pstate@2 {
> +				reg = <2>;
> +				domain-microvolt = <1000000 1075000 1085000>;
> +			};
> +		};
> +	}
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			compatible = "arm,cortex-a9";
> +			reg = <0>;
> +			clocks = <&clk_controller 0>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +			power-domains = <&foo_domain>;
> +		};
> +	};
> +};
> -- 
> 2.7.1.410.g6faf27b
> 

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rafael Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Kevin Hilman <khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Viresh Kumar <vireshk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Vincent Guittot
	<vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes
Date: Mon, 27 Feb 2017 18:39:48 -0600	[thread overview]
Message-ID: <20170228003948.ihf4c2ppu2rf3lt2@rob-hp-laptop> (raw)
In-Reply-To: <ceb1bf5f696138c30b30743c24b619336d438d7c.1487926924.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Fri, Feb 24, 2017 at 02:36:34PM +0530, Viresh Kumar wrote:
> 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 nodes directly.
> 
> But if the device needs the capability of switching to different domain
> performance states, as they may need to support different clock rates,
> then the per OPP node can be used to contain that information.
> 
> This patch introduces the domain-performance-state (already defined by
> Power Domain bindings) to the per OPP node.
> 

We already have OPP voltages, why are those not sufficient?

> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Tested-by: Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 64 +++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 9f5ca4457b5f..7f6bb52521b6 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -154,6 +154,15 @@ properties.
>  
>  - status: Marks the node enabled/disabled.
>  
> +- domain-performance-state: A positive integer value representing the minimum
> +  performance level (of the parent domain) required by the consumer as defined
> +  by ../power/power_domain.txt binding document. The OPP nodes can contain the
> +  "domain-performance-state" property, only if the device node contains a
> +  "power-domains" property. The OPP nodes aren't allowed to contain the
> +  "domain-performance-state" property partially, i.e. Either all OPP nodes in
> +  the OPP table have the "domain-performance-state" property or none of them
> +  have it.
> +
>  Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>  
>  / {
> @@ -528,3 +537,58 @@ Example 5: opp-supported-hw
>  		};
>  	};
>  };
> +
> +Example 7: domain-Performance-state:
> +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> +
> +/ {
> +	cpu0_opp_table: opp_table0 {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp@1000000000 {
> +			opp-hz = /bits/ 64 <1000000000>;
> +			domain-performance-state = <1>;

Thinking about this some more, there's a problem here that you have no 
link to foo_domain. I guess that resides in the cpu's node?

Perhaps instead of a number, this should be a phandle to pstate@1. Then 
you just get the parent if you need to know the domain.

> +		};
> +		opp@1100000000 {
> +			opp-hz = /bits/ 64 <1100000000>;
> +			domain-performance-state = <2>;
> +		};
> +		opp@1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
> +			domain-performance-state = <2>;
> +		};
> +	};
> +
> +	foo_domain: power-controller@12340000 {
> +		compatible = "foo,power-controller";
> +		reg = <0x12340000 0x1000>;
> +		#power-domain-cells = <0>;
> +
> +		performance-states {
> +			compatible = "domain-performance-state";
> +			pstate@1 {
> +				reg = <1>;
> +				domain-microvolt = <970000 975000 985000>;
> +			};
> +			pstate@2 {
> +				reg = <2>;
> +				domain-microvolt = <1000000 1075000 1085000>;
> +			};
> +		};
> +	}
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			compatible = "arm,cortex-a9";
> +			reg = <0>;
> +			clocks = <&clk_controller 0>;
> +			clock-names = "cpu";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +			power-domains = <&foo_domain>;
> +		};
> +	};
> +};
> -- 
> 2.7.1.410.g6faf27b
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-02-28  0:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24  9:06 [PATCH V3 0/7] PM / Domains: Implement domain performance states Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding Viresh Kumar
2017-02-24  9:06   ` Viresh Kumar
2017-02-28  0:31   ` Rob Herring
2017-02-28  0:31     ` Rob Herring
2017-02-28  5:36     ` Viresh Kumar
2017-02-28  5:36       ` Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 2/7] PM / OPP: Introduce "domain-performance-state" binding to OPP nodes Viresh Kumar
2017-02-24  9:06   ` Viresh Kumar
2017-02-28  0:39   ` Rob Herring [this message]
2017-02-28  0:39     ` Rob Herring
2017-02-28  6:57     ` Viresh Kumar
2017-02-28  6:57       ` Viresh Kumar
2017-02-28 14:10       ` Rob Herring
2017-02-28 14:10         ` Rob Herring
2017-02-28 15:14         ` Ulf Hansson
2017-02-28 15:14           ` Ulf Hansson
2017-02-28 15:52           ` Rob Herring
2017-02-28 15:52             ` Rob Herring
2017-02-28 19:13             ` Geert Uytterhoeven
2017-03-01  6:14             ` Viresh Kumar
2017-03-01  8:45               ` Geert Uytterhoeven
2017-03-01  8:54                 ` Viresh Kumar
2017-03-01  6:27             ` Rajendra Nayak
2017-03-01 23:13               ` Rob Herring
2017-03-02  3:30                 ` Rajendra Nayak
2017-03-01  6:12         ` Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 3/7] PM / QOS: Keep common notifier list for genpd constraints Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 4/7] PM / QOS: Add DEV_PM_QOS_PERFORMANCE request Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 5/7] PM / domain: Register for PM QOS performance notifier Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 6/7] PM / Domains: Allow domain performance states to be read from DT Viresh Kumar
2017-02-24  9:06 ` [PATCH V3 7/7] PM / OPP: Add support to parse domain-performance-state Viresh Kumar
2017-03-10 20:38 ` [PATCH V3 0/7] PM / Domains: Implement domain performance states Kevin Hilman
2017-03-13 10:39   ` Viresh Kumar
2017-03-15 10:49     ` 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=20170228003948.ihf4c2ppu2rf3lt2@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@linaro.org \
    --cc=lina.iyer@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@kernel.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.