[PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

[PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

[Viresh Kumar]

Hello,

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.

We had some discussions about it in the past on the PM list [1], which is
followed by discussions during the LPC. The outcome of all that was that we
should extend Power Domain framework to support active state power management
as well.

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.

To get a complete picture of the proposed plan, following is what we
need to do:
- Create DT bindings to get domain performance state information for the
  platforms.
- Enhance OPP framework to parse these and call into the PM Qos
  framework with a performance state request.
- Enhance PM Qos framework to provide the API to be used by consumers
  (or OPP framework) and pass it on to the (Generic) Power Domain
  framework.
- Enhance Generic Power Domain framework to accept such requests,
  accumulate all belonging to a single power domain and call domain
  driver specific callback with the performance state we want for the
  domain.
- The domain driver shall then, in a platform specific way, set the
  requested performance level.
- Note that these features are applicable to the CPU, GPU and other IIO
  or non-IIO devices.
- There can be cases where a device can choose between multiple power
  domains based on what performance level we want for the device. In
  such cases, we should represent the multiplexer with a separate power
  domain. In effect, the device (or OPP table) will correspond to a
  single power domain, but the backend driver of that domain shall
  implement the multiplexing functionality.

This patchset implements the very first part of this chain and
introduces a new optional property for the consumers of the
power-domains: domain-performance-state. This property can be used
directly by the consumer or its OPP table.

V1->V2:
- The performance states get their own nodes as they can have multiple
  values.
- Allow optional property domain-microvolt for the performance states

--
viresh

[1] https://marc.info/?l=linux-pm&m=147747923708075&w=2

Viresh Kumar (2):
  PM / Domains: Introduce domain-performance-states binding
  PM / OPP: Introduce domain-performance-state binding to OPP nodes

 Documentation/devicetree/bindings/opp/opp.txt      | 59 ++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     | 69 ++++++++++++++++++++++
 2 files changed, 128 insertions(+)

-- 
2.7.1.410.g6faf27b

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

[Viresh Kumar]

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

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

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

[Rob Herring]

On Mon, Dec 12, 2016 at 04:26:18PM +0530, 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.
> 
> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 {

If you want to have performance states for a domain in DT, then you need 
to actually have a node for the domain in DT. Then this should be a 
child of the domain. I wouldn't think non-CPU domain performance states 
will be common across domains.

> +		compatible = "domain-performance-state";
> +		domain_perf_state1: pstate@1 {

A unit address should have a reg property.

> +			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>;

domain-performance-state and domain-performance-states are too similar 
in name. The property here should probably reflect the mode needed and 
perhaps specific to the device. I assume a device will need multiple 
states/modes.

Also, since you refer to the performance state node directly, I'm not 
sure why you need the performance-level property.

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

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

[Viresh Kumar]

On 22-12-16, 12:34, Rob Herring wrote:
> > +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 {
> 
> If you want to have performance states for a domain in DT, then you need 
> to actually have a node for the domain in DT. Then this should be a 
> child of the domain. I wouldn't think non-CPU domain performance states 
> will be common across domains.

So you suggest something like this then ?

+       parent: power-controller@12340000 {
+               compatible = "foo,power-controller";
+               reg = <0x12340000 0x1000>;
+               #power-domain-cells = <0>;
+
+               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>;
+                       };
+               }
+       };
+

> 
> > +		compatible = "domain-performance-state";
> > +		domain_perf_state1: pstate@1 {
> 
> A unit address should have a reg property.

There is no register address here. Similar problem as the OPP table
where we ended up using the frequency. What should we do here ?

> > +			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>;
> 
> domain-performance-state and domain-performance-states are too similar 
> in name. The property here should probably reflect the mode needed and 
> perhaps specific to the device.

Its the state of its power domain which is required for the
functioning of the device.

> I assume a device will need multiple states/modes.

Such devices are handled by the 2nd patch, which uses OPP table for
this. The above example is for simple devices, which have a fixed
requirement.

> Also, since you refer to the performance state node directly, I'm not 
> sure why you need the performance-level property.

That value will be used by the genpd core to pass on to the platform
specific code which will take care of updating the domain state. For
example in case of Qcom, it is a separate M3 core which accepts these
values.

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

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

[Rajendra Nayak]

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

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

[Viresh Kumar]

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

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

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

[Rajendra Nayak]

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

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

[Viresh Kumar]

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

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

[Rajendra Nayak]

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

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

[Viresh Kumar]

On 06-01-17, 16:06, Rajendra Nayak wrote:
> No, I am thoroughly confused :)
> I was struggling with 2 powerdomains and now there are way too many of them :P

For the record, we had some offline chat and his case is pretty much
taken care of by the proposed bindings. Though he will look in more
details and post further queries later. :)

-- 
viresh

[PATCH V2 2/2] PM / OPP: Introduce domain-performance-state binding to OPP nodes

[Viresh Kumar]

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.

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.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 Documentation/devicetree/bindings/opp/opp.txt | 59 +++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 9f5ca4457b5f..43eba7c9fc58 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -154,6 +154,9 @@ properties.
 
 - status: Marks the node enabled/disabled.
 
+- domain-performance-state: A phandle of a Performance state node as defined by
+  ../power/power_domain.txt binding document.
+
 Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
 
 / {
@@ -528,3 +531,59 @@ 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)
+
+/ {
+	foo_domain: 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>;
+		};
+	}
+
+	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>;
+		};
+	};
+
+	cpu0_opp_table: opp_table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp@1000000000 {
+			opp-hz = /bits/ 64 <1000000000>;
+			domain-performance-state = <&domain_perf_state1>;
+		};
+		opp@1100000000 {
+			opp-hz = /bits/ 64 <1100000000>;
+			domain-performance-state = <&domain_perf_state2>;
+		};
+		opp@1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
+			domain-performance-state = <&domain_perf_state2>;
+		};
+	};
+};
-- 
2.7.1.410.g6faf27b

Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

[Rob Herring]

On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> Hello,
> 
> 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.
> 
> We had some discussions about it in the past on the PM list [1], which is
> followed by discussions during the LPC. The outcome of all that was that we
> should extend Power Domain framework to support active state power management
> as well.
> 
> 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.

>From a h/w perspective, are idle states really different from 
performance states? 

> 
> To get a complete picture of the proposed plan, following is what we
> need to do:
> - Create DT bindings to get domain performance state information for the
>   platforms.

I would do this last so you can evolve things if you're not certain 
about what the bindings should look like. You can always start with 
things in the kernel and add to DT later.

While in theory we should be able to just "describe the h/w" in DT and 
develop the Linux side independently, this feels too much like the 
bindings are just evolving with Linux needs.

Rob

Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

[Viresh Kumar]

On 22-12-16, 12:14, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> > Hello,
> > 
> > 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.
> > 
> > We had some discussions about it in the past on the PM list [1], which is
> > followed by discussions during the LPC. The outcome of all that was that we
> > should extend Power Domain framework to support active state power management
> > as well.
> > 
> > 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.
> 
> From a h/w perspective, are idle states really different from 
> performance states? 

Its a tricky question TBH :)

The device is almost powered off during the idle states, while
performance states here are the functioning of the device. I haven't
answered your question well, perhaps I need a more direct question :)

> > To get a complete picture of the proposed plan, following is what we
> > need to do:
> > - Create DT bindings to get domain performance state information for the
> >   platforms.
> 
> I would do this last so you can evolve things if you're not certain 
> about what the bindings should look like. You can always start with 
> things in the kernel and add to DT later.

I didn't knew that and it looks like a very good option. I am not sure
if I would like to do that for this series though. Maybe lets discuss
the bindings a bit more and if we aren't able to find a common ground,
I can try code first.

> While in theory we should be able to just "describe the h/w" in DT and 

Right.

> develop the Linux side independently, this feels too much like the 
> bindings are just evolving with Linux needs.

:)

-- 
viresh

Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

[Viresh Kumar]

On 22-12-16, 12:14, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> > Hello,
> > 
> > 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.
> > 
> > We had some discussions about it in the past on the PM list [1], which is
> > followed by discussions during the LPC. The outcome of all that was that we
> > should extend Power Domain framework to support active state power management
> > as well.
> > 
> > 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.
> 
> >From a h/w perspective, are idle states really different from 
> performance states? 
> 
> > 
> > To get a complete picture of the proposed plan, following is what we
> > need to do:
> > - Create DT bindings to get domain performance state information for the
> >   platforms.
> 
> I would do this last so you can evolve things if you're not certain 
> about what the bindings should look like. You can always start with 
> things in the kernel and add to DT later.

Okay, I have just posted some code for this:

lkml.kernel.org/r/cover.1483439894.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org

Thanks for your inputs.

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