[V2,1/2] PM / Domains: Introduce domain-performance-states binding

Message ID dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar@linaro.org
State New
Headers show

Commit Message

Viresh Kumar Dec. 12, 2016, 10:56 a.m.
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.

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(+)

-- 
2.7.1.410.g6faf27b

Comments

Rajendra Nayak Jan. 6, 2017, 8:46 a.m. | #1
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
Rajendra Nayak Jan. 6, 2017, 10:12 a.m. | #2
On 01/06/2017 02:57 PM, Viresh Kumar wrote:
> On 06-01-17, 14:16, Rajendra Nayak wrote:

>>

>> 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.

> 

> I have answered a similar question here..

> 

> https://marc.info/?l=linux-kernel&m=148067565219477&w=2


I read through that discussion, and I thought that was to do we
handling multiple powerdomains with performance states
(or in other words multiple voltage rails controlled by the M3)

What I was pointing to, was that devices quite often (again on qcom
platforms) have a power-switch (gdscs as we call it) which are modeled
as powerdomains (which have nothing to do with taking to the M3 core),
and with the proposed bindings one or more voltage rails controlled by the M3
also as powerdomains associated with a device and the bindings have just one
power-domains property in the device node, which runtime PM would use
to power_on/off the device and OPP core would use to set the performance
state?

+	leaky-device@12350000 {
+		compatible = "foo,i-leak-current";
+		reg = <0x12350000 0x1000>;
+		power-domains = <&power 0>;
+		domain-performance-state = <&domain_perf_state2>;
+	};

Lets say leaky-device needs to switch on/off a gdsc and also send a
value to M3 to set a minimum performance state (so M3 configures the
voltage rails accordingly) how would it work?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Viresh Kumar Jan. 6, 2017, 10:23 a.m. | #3
On 06-01-17, 15:42, Rajendra Nayak wrote:
> I read through that discussion, and I thought that was to do we

> handling multiple powerdomains with performance states

> (or in other words multiple voltage rails controlled by the M3)


I thought about it as multiple power domains available for a device,
and the device will be in a single domain out of those at a time. So
perhaps it is about the problem you mentioned.

> What I was pointing to, was that devices quite often (again on qcom

> platforms) have a power-switch (gdscs as we call it) which are modeled

> as powerdomains (which have nothing to do with taking to the M3 core),

> and with the proposed bindings one or more voltage rails controlled by the M3

> also as powerdomains associated with a device and the bindings have just one

> power-domains property in the device node, which runtime PM would use

> to power_on/off the device and OPP core would use to set the performance

> state?

> 

> +	leaky-device@12350000 {

> +		compatible = "foo,i-leak-current";

> +		reg = <0x12350000 0x1000>;

> +		power-domains = <&power 0>;

> +		domain-performance-state = <&domain_perf_state2>;

> +	};

> 

> Lets say leaky-device needs to switch on/off a gdsc and also send a

> value to M3 to set a minimum performance state (so M3 configures the

> voltage rails accordingly) how would it work?


So the way I proposed this earlier is that every device will have a
single power domain for it. In your case that power domain will
represent gdscs. Idle state and performance state request will go to
that level and then its up to the gdscs domain specific code to choose
the right domain and its performance state. The parent domain shall
then pass on the performance state to the next level power domain
controlled by the M3 core.

For example a device can have I power domain for idle state management
and A power domain for active state management. The device will also
have a M power domain which represents the gdscs. M can choose I or A
as its parent. The power domain A (and similar power domains for all
other devices) will have a parent power domain P. Now P is controlled
or configured via the M3. Will that make sense ?

-- 
viresh
Rajendra Nayak Jan. 6, 2017, 10:36 a.m. | #4
On 01/06/2017 03:53 PM, Viresh Kumar wrote:
> On 06-01-17, 15:42, Rajendra Nayak wrote:

>> I read through that discussion, and I thought that was to do we

>> handling multiple powerdomains with performance states

>> (or in other words multiple voltage rails controlled by the M3)

> 

> I thought about it as multiple power domains available for a device,

> and the device will be in a single domain out of those at a time. So

> perhaps it is about the problem you mentioned.

> 

>> What I was pointing to, was that devices quite often (again on qcom

>> platforms) have a power-switch (gdscs as we call it) which are modeled

>> as powerdomains (which have nothing to do with taking to the M3 core),

>> and with the proposed bindings one or more voltage rails controlled by the M3

>> also as powerdomains associated with a device and the bindings have just one

>> power-domains property in the device node, which runtime PM would use

>> to power_on/off the device and OPP core would use to set the performance

>> state?

>>

>> +	leaky-device@12350000 {

>> +		compatible = "foo,i-leak-current";

>> +		reg = <0x12350000 0x1000>;

>> +		power-domains = <&power 0>;

>> +		domain-performance-state = <&domain_perf_state2>;

>> +	};

>>

>> Lets say leaky-device needs to switch on/off a gdsc and also send a

>> value to M3 to set a minimum performance state (so M3 configures the

>> voltage rails accordingly) how would it work?

> 

> So the way I proposed this earlier is that every device will have a

> single power domain for it. In your case that power domain will

> represent gdscs. Idle state and performance state request will go to

> that level and then its up to the gdscs domain specific code to choose

> the right domain and its performance state. The parent domain shall

> then pass on the performance state to the next level power domain

> controlled by the M3 core.

> 

> For example a device can have I power domain for idle state management

> and A power domain for active state management. The device will also

> have a M power domain which represents the gdscs. M can choose I or A

> as its parent. The power domain A (and similar power domains for all

> other devices) will have a parent power domain P. Now P is controlled

> or configured via the M3. Will that make sense ?


No, I am thoroughly confused :)
I was struggling with 2 powerdomains and now there are way too many of them :P

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Patch

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