| Message ID | dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar@linaro.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 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.. > > 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?
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. :)
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
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(+)