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(+)
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
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@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 powerdomain.- 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
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.
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 powerdomain.- 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
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
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..
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?
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 ?
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
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. :)
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>; + }; + }; +};
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
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.
:)
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@linaro.org
Thanks for your inputs.
linaro-kernel@lists.linaro.org
-
Rajendra Nayak -
Rob Herring -
Viresh Kumar