| Message ID | 132e9200102bf2f1175567f0862596d098363d9e.1487926924.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [V3,1/7] PM / Domains: Introduce "performance-states" binding | expand |
On Fri, Feb 24, 2017 at 02:36:33PM +0530, Viresh Kumar wrote: > Some platforms have the capability to configure the performance state of > their power domains. The process of configuring the performance state is > pretty much platform dependent and we may need to work with a wide range > of configurables. For some platforms, like Qcom, it can be a positive > integer value alone, while in other cases it can be voltage levels, etc. > > The power-domain framework until now was only designed for the idle > state management of the device and this needs to change in order to > reuse the power-domain framework for active state management of the > devices. > > This patch adds DT bindings to describe the performance states of a > power domain. The power domain node needs to contain a > "performance-states" node, which itself is an array of per-state nodes. > Each per-state node represents individual performance state of a device. > Individual nodes are identified by their (mandatory) "reg" field. These > nodes can also contain an optional "domain-microvolt" property. More > properties can be added later on once we have more platforms using it. > > 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 using the > "domain-performance-state" property. Otherwise the consumers can define > their requirements with help of other infrastructure, for example the > OPP table (added in a later commit). > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > Tested-by: Rajendra Nayak <rnayak@codeaurora.org> > --- > .../devicetree/bindings/power/power_domain.txt | 67 ++++++++++++++++++++++ > 1 file changed, 67 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt > index 723e1ad937da..9be09e576f68 100644 > --- a/Documentation/devicetree/bindings/power/power_domain.txt > +++ b/Documentation/devicetree/bindings/power/power_domain.txt > @@ -38,6 +38,33 @@ 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. > > +- performance-states : This describes the performance states of a PM domain. > + The performance-states node reflects the performance states of this PM domain > + and not the performance states of the devices or sub-domains in the PM domain. > + Sub domains can have their own performance states. Sub domains without their > + own performance states are governed by the performance states of the parent > + domain and the "domain-performance-state" properties of their consumers refer > + to the "reg" properties of the nodes in the parent domain. > + > + Required properties of the performance-states node: > + - compatible: Allow performance states to express their compatibility. It > + should be: "domain-performance-state". > + > + - nodes: The performance-states node should contain one or > + more nodes, each representing a supported performance state. > + > + Required properties of the performance state nodes: > + - reg: A positive integer value representing the performance level > + associated with a performance state. The integer value '0' represents the > + lowest performance level and the highest value represents the highest > + performance level. The exact meaning and performance implications of > + individual values is left to be defined by the user platform. > + > + Optional properties of performance state nodes: > + - 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 +145,44 @@ 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 positive integer value representing the minimum > + performance level (of the parent domain) required by the consumer for its > + working. The integer value '0' represents the lowest performance level and the > + highest value represents the highest performance level. The value of > + domain-performance-state field should match one of the "reg" fields in the > + "performance-states" table of the parent power domain. > + > + > +Example: > + > + parent: 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>; This doesn't look like "<target> <min> <max>". With that fixed, Acked-by: Rob Herring <robh@kernel.org> > + }; > + pstate@2 { > + reg = <2>; > + domain-microvolt = <1000000 1075000 1085000>; > + }; > + pstate@3 { > + reg = <3>; > + domain-microvolt = <1100000 1175000 1185000>; > + }; > + }; > + }; > + > + leaky-device@12350000 { > + compatible = "foo,i-leak-current"; > + reg = <0x12350000 0x1000>; > + power-domains = <&power 0>; > + domain-performance-state = <2>; > + }; > + > [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt > -- > 2.7.1.410.g6faf27b > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27-02-17, 18:31, Rob Herring wrote: > On Fri, Feb 24, 2017 at 02:36:33PM +0530, Viresh Kumar wrote: > > Some platforms have the capability to configure the performance state of > > their power domains. The process of configuring the performance state is > > pretty much platform dependent and we may need to work with a wide range > > of configurables. For some platforms, like Qcom, it can be a positive > > integer value alone, while in other cases it can be voltage levels, etc. > > > > The power-domain framework until now was only designed for the idle > > state management of the device and this needs to change in order to > > reuse the power-domain framework for active state management of the > > devices. > > > > This patch adds DT bindings to describe the performance states of a > > power domain. The power domain node needs to contain a > > "performance-states" node, which itself is an array of per-state nodes. > > Each per-state node represents individual performance state of a device. > > Individual nodes are identified by their (mandatory) "reg" field. These > > nodes can also contain an optional "domain-microvolt" property. More > > properties can be added later on once we have more platforms using it. > > > > 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 using the > > "domain-performance-state" property. Otherwise the consumers can define > > their requirements with help of other infrastructure, for example the > > OPP table (added in a later commit). > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > Tested-by: Rajendra Nayak <rnayak@codeaurora.org> > > --- > > .../devicetree/bindings/power/power_domain.txt | 67 ++++++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt > > index 723e1ad937da..9be09e576f68 100644 > > --- a/Documentation/devicetree/bindings/power/power_domain.txt > > +++ b/Documentation/devicetree/bindings/power/power_domain.txt > > @@ -38,6 +38,33 @@ 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. > > > > +- performance-states : This describes the performance states of a PM domain. > > + The performance-states node reflects the performance states of this PM domain > > + and not the performance states of the devices or sub-domains in the PM domain. > > + Sub domains can have their own performance states. Sub domains without their > > + own performance states are governed by the performance states of the parent > > + domain and the "domain-performance-state" properties of their consumers refer > > + to the "reg" properties of the nodes in the parent domain. > > + > > + Required properties of the performance-states node: > > + - compatible: Allow performance states to express their compatibility. It > > + should be: "domain-performance-state". > > + > > + - nodes: The performance-states node should contain one or > > + more nodes, each representing a supported performance state. > > + > > + Required properties of the performance state nodes: > > + - reg: A positive integer value representing the performance level > > + associated with a performance state. The integer value '0' represents the > > + lowest performance level and the highest value represents the highest > > + performance level. The exact meaning and performance implications of > > + individual values is left to be defined by the user platform. > > + > > + Optional properties of performance state nodes: > > + - 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 +145,44 @@ 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 positive integer value representing the minimum > > + performance level (of the parent domain) required by the consumer for its > > + working. The integer value '0' represents the lowest performance level and the > > + highest value represents the highest performance level. The value of > > + domain-performance-state field should match one of the "reg" fields in the > > + "performance-states" table of the parent power domain. > > + > > + > > +Example: > > + > > + parent: 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>; > > This doesn't look like "<target> <min> <max>". Wow, even the examples in the OPP document have these screwed up :( > With that fixed, > > Acked-by: Rob Herring <robh@kernel.org> Thanks. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 723e1ad937da..9be09e576f68 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -38,6 +38,33 @@ 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. +- performance-states : This describes the performance states of a PM domain. + The performance-states node reflects the performance states of this PM domain + and not the performance states of the devices or sub-domains in the PM domain. + Sub domains can have their own performance states. Sub domains without their + own performance states are governed by the performance states of the parent + domain and the "domain-performance-state" properties of their consumers refer + to the "reg" properties of the nodes in the parent domain. + + Required properties of the performance-states node: + - compatible: Allow performance states to express their compatibility. It + should be: "domain-performance-state". + + - nodes: The performance-states node should contain one or + more nodes, each representing a supported performance state. + + Required properties of the performance state nodes: + - reg: A positive integer value representing the performance level + associated with a performance state. The integer value '0' represents the + lowest performance level and the highest value represents the highest + performance level. The exact meaning and performance implications of + individual values is left to be defined by the user platform. + + Optional properties of performance state nodes: + - 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 +145,44 @@ 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 positive integer value representing the minimum + performance level (of the parent domain) required by the consumer for its + working. The integer value '0' represents the lowest performance level and the + highest value represents the highest performance level. The value of + domain-performance-state field should match one of the "reg" fields in the + "performance-states" table of the parent power domain. + + +Example: + + parent: 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>; + }; + pstate@3 { + reg = <3>; + domain-microvolt = <1100000 1175000 1185000>; + }; + }; + }; + + leaky-device@12350000 { + compatible = "foo,i-leak-current"; + reg = <0x12350000 0x1000>; + power-domains = <&power 0>; + domain-performance-state = <2>; + }; + [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt