| Message ID | 20201224111210.1214-2-rojay@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add support for assigned-performance-states for geni i2c driver | expand |
On Thu, 24 Dec 2020 16:42:08 +0530, Roja Rani Yarubandi wrote: > While most devices within power-domains which support performance states, > scale the performance state dynamically, some devices might want to > set a static/default performance state while the device is active. > These devices typically would also run off a fixed clock and not support > dynamically scaling the device's performance, also known as DVFS > techniques. > > Add a property 'assigned-performance-states' which client devices can > use to set this default performance state on their power-domains. > > Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> > --- > .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ > 1 file changed, 49 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/power/power-domain.yaml:72:8: [warning] wrong indentation: expected 6 but found 7 (indentation) dtschema/dtc warnings/errors: See https://patchwork.ozlabs.org/patch/1420485 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On Thu, 24 Dec 2020 16:42:08 +0530, Roja Rani Yarubandi wrote: > While most devices within power-domains which support performance states, > scale the performance state dynamically, some devices might want to > set a static/default performance state while the device is active. > These devices typically would also run off a fixed clock and not support > dynamically scaling the device's performance, also known as DVFS > techniques. > > Add a property 'assigned-performance-states' which client devices can > use to set this default performance state on their power-domains. > > Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> > --- > .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ > 1 file changed, 49 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: ./Documentation/devicetree/bindings/power/power-domain.yaml:72:8: [warning] wrong indentation: expected 6 but found 7 (indentation) dtschema/dtc warnings/errors: See https://patchwork.ozlabs.org/patch/1420485 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On Thu, Dec 24, 2020 at 04:42:08PM +0530, Roja Rani Yarubandi wrote: > While most devices within power-domains which support performance states, > scale the performance state dynamically, some devices might want to > set a static/default performance state while the device is active. > These devices typically would also run off a fixed clock and not support > dynamically scaling the device's performance, also known as DVFS > techniques. > > Add a property 'assigned-performance-states' which client devices can > use to set this default performance state on their power-domains. > > Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> > --- > .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml > index aed51e9dcb11..a42977a82d06 100644 > --- a/Documentation/devicetree/bindings/power/power-domain.yaml > +++ b/Documentation/devicetree/bindings/power/power-domain.yaml > @@ -66,6 +66,18 @@ properties: > by the given provider should be subdomains of the domain specified > by this binding. > > + assigned-performance-states: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > + Some devices might need to configure their power domains in a default > + performance state while the device is active. These devices typcially > + would also run off a fixed clock and not support dynamically scaling > + the device's performance, also known as DVFS techniques. Each cell in > + performance state value corresponds to one power domain specified as > + part of the power-domains property. Performance state value can be an > + opp-level inside an OPP table of the power-domain and need not match > + with any OPP table performance state. Couldn't this just be an additional cell in 'power-domains'? > + > required: > - "#power-domain-cells" > > @@ -131,3 +143,40 @@ examples: > min-residency-us = <7000>; > }; > }; > + > + - | > + parent4: power-controller@12340000 { > + compatible = "foo,power-controller"; > + reg = <0x12340000 0x1000>; > + #power-domain-cells = <0>; > + }; > + > + parent5: power-controller@43210000 { > + compatible = "foo,power-controller"; > + reg = <0x43210000 0x1000>; > + #power-domain-cells = <0>; > + operating-points-v2 = <&power_opp_table>; > + > + power_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + power_opp_low: opp1 { > + opp-level = <16>; > + }; > + > + rpmpd_opp_ret: opp2 { > + opp-level = <64>; > + }; > + > + rpmpd_opp_svs: opp3 { > + opp-level = <256>; > + }; > + }; > + }; > + > + child4: consumer@12341000 { > + compatible = "foo,consumer"; > + reg = <0x12341000 0x1000>; > + power-domains = <&parent4>, <&parent5>; > + assigned-performance-states = <0>, <256>; > + }; > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
On Thu, 31 Dec 2020 at 16:49, Rob Herring <robh@kernel.org> wrote: > > On Thu, Dec 24, 2020 at 04:42:08PM +0530, Roja Rani Yarubandi wrote: > > While most devices within power-domains which support performance states, > > scale the performance state dynamically, some devices might want to > > set a static/default performance state while the device is active. > > These devices typically would also run off a fixed clock and not support > > dynamically scaling the device's performance, also known as DVFS > > techniques. > > > > Add a property 'assigned-performance-states' which client devices can > > use to set this default performance state on their power-domains. > > > > Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> > > --- > > .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml > > index aed51e9dcb11..a42977a82d06 100644 > > --- a/Documentation/devicetree/bindings/power/power-domain.yaml > > +++ b/Documentation/devicetree/bindings/power/power-domain.yaml > > @@ -66,6 +66,18 @@ properties: > > by the given provider should be subdomains of the domain specified > > by this binding. > > > > + assigned-performance-states: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: > > + Some devices might need to configure their power domains in a default > > + performance state while the device is active. These devices typcially > > + would also run off a fixed clock and not support dynamically scaling > > + the device's performance, also known as DVFS techniques. Each cell in > > + performance state value corresponds to one power domain specified as > > + part of the power-domains property. Performance state value can be an > > + opp-level inside an OPP table of the power-domain and need not match > > + with any OPP table performance state. > > Couldn't this just be an additional cell in 'power-domains'? Right. Some SoCs already use the cell to specify per device SoC specific data [1]. Although, I am wondering if we shouldn't consider "assigned-performance-states" as a more generic binding. I think it would be somewhat comparable with the existing "assigned-clock-rates" binding, don't you think? [...] Kind regards Uffe [1] Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi wrote: > While most devices within power-domains which support performance states, > scale the performance state dynamically, some devices might want to > set a static/default performance state while the device is active. > These devices typically would also run off a fixed clock and not support > dynamically scaling the device's performance, also known as DVFS > techniques. > > Add a property 'assigned-performance-states' which client devices can > use to set this default performance state on their power-domains. > > Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> > --- > .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml > index aed51e9dcb11..a42977a82d06 100644 > --- a/Documentation/devicetree/bindings/power/power-domain.yaml > +++ b/Documentation/devicetree/bindings/power/power-domain.yaml > @@ -66,6 +66,18 @@ properties: > by the given provider should be subdomains of the domain specified > by this binding. > > + assigned-performance-states: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: > + Some devices might need to configure their power domains in a default > + performance state while the device is active. These devices typcially > + would also run off a fixed clock and not support dynamically scaling > + the device's performance, also known as DVFS techniques. Each cell in > + performance state value corresponds to one power domain specified as > + part of the power-domains property. Performance state value can be an > + opp-level inside an OPP table of the power-domain and need not match > + with any OPP table performance state. > + > required: > - "#power-domain-cells" > > @@ -131,3 +143,40 @@ examples: > min-residency-us = <7000>; > }; > }; > + > + - | > + parent4: power-controller@12340000 { > + compatible = "foo,power-controller"; > + reg = <0x12340000 0x1000>; > + #power-domain-cells = <0>; > + }; > + > + parent5: power-controller@43210000 { > + compatible = "foo,power-controller"; > + reg = <0x43210000 0x1000>; > + #power-domain-cells = <0>; > + operating-points-v2 = <&power_opp_table>; > + > + power_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + power_opp_low: opp1 { > + opp-level = <16>; > + }; > + > + rpmpd_opp_ret: opp2 { > + opp-level = <64>; > + }; > + > + rpmpd_opp_svs: opp3 { > + opp-level = <256>; > + }; > + }; > + }; > + > + child4: consumer@12341000 { > + compatible = "foo,consumer"; > + reg = <0x12341000 0x1000>; > + power-domains = <&parent4>, <&parent5>; > + assigned-performance-states = <0>, <256>; May I ask how this is different from saying something like: required-opps = <&??>, <&rpmpd_opp_svs>: Regards, Bjorn > + }; > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation >
On 1/15/2021 9:45 PM, Bjorn Andersson wrote: > On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi wrote: > >> While most devices within power-domains which support performance states, >> scale the performance state dynamically, some devices might want to >> set a static/default performance state while the device is active. >> These devices typically would also run off a fixed clock and not support >> dynamically scaling the device's performance, also known as DVFS >> techniques. >> >> Add a property 'assigned-performance-states' which client devices can >> use to set this default performance state on their power-domains. >> >> Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> >> --- >> .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ >> 1 file changed, 49 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml >> index aed51e9dcb11..a42977a82d06 100644 >> --- a/Documentation/devicetree/bindings/power/power-domain.yaml >> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml >> @@ -66,6 +66,18 @@ properties: >> by the given provider should be subdomains of the domain specified >> by this binding. >> >> + assigned-performance-states: >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + description: >> + Some devices might need to configure their power domains in a default >> + performance state while the device is active. These devices typcially >> + would also run off a fixed clock and not support dynamically scaling >> + the device's performance, also known as DVFS techniques. Each cell in >> + performance state value corresponds to one power domain specified as >> + part of the power-domains property. Performance state value can be an >> + opp-level inside an OPP table of the power-domain and need not match >> + with any OPP table performance state. >> + >> required: >> - "#power-domain-cells" >> >> @@ -131,3 +143,40 @@ examples: >> min-residency-us = <7000>; >> }; >> }; >> + >> + - | >> + parent4: power-controller@12340000 { >> + compatible = "foo,power-controller"; >> + reg = <0x12340000 0x1000>; >> + #power-domain-cells = <0>; >> + }; >> + >> + parent5: power-controller@43210000 { >> + compatible = "foo,power-controller"; >> + reg = <0x43210000 0x1000>; >> + #power-domain-cells = <0>; >> + operating-points-v2 = <&power_opp_table>; >> + >> + power_opp_table: opp-table { >> + compatible = "operating-points-v2"; >> + >> + power_opp_low: opp1 { >> + opp-level = <16>; >> + }; >> + >> + rpmpd_opp_ret: opp2 { >> + opp-level = <64>; >> + }; >> + >> + rpmpd_opp_svs: opp3 { >> + opp-level = <256>; >> + }; >> + }; >> + }; >> + >> + child4: consumer@12341000 { >> + compatible = "foo,consumer"; >> + reg = <0x12341000 0x1000>; >> + power-domains = <&parent4>, <&parent5>; >> + assigned-performance-states = <0>, <256>; > > May I ask how this is different from saying something like: > > required-opps = <&??>, <&rpmpd_opp_svs>: I think its potentially the same. We just don't have any code to handle this binding in kernel yet (when this property is part of the device/consumer node)
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml index aed51e9dcb11..a42977a82d06 100644 --- a/Documentation/devicetree/bindings/power/power-domain.yaml +++ b/Documentation/devicetree/bindings/power/power-domain.yaml @@ -66,6 +66,18 @@ properties: by the given provider should be subdomains of the domain specified by this binding. + assigned-performance-states: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Some devices might need to configure their power domains in a default + performance state while the device is active. These devices typcially + would also run off a fixed clock and not support dynamically scaling + the device's performance, also known as DVFS techniques. Each cell in + performance state value corresponds to one power domain specified as + part of the power-domains property. Performance state value can be an + opp-level inside an OPP table of the power-domain and need not match + with any OPP table performance state. + required: - "#power-domain-cells" @@ -131,3 +143,40 @@ examples: min-residency-us = <7000>; }; }; + + - | + parent4: power-controller@12340000 { + compatible = "foo,power-controller"; + reg = <0x12340000 0x1000>; + #power-domain-cells = <0>; + }; + + parent5: power-controller@43210000 { + compatible = "foo,power-controller"; + reg = <0x43210000 0x1000>; + #power-domain-cells = <0>; + operating-points-v2 = <&power_opp_table>; + + power_opp_table: opp-table { + compatible = "operating-points-v2"; + + power_opp_low: opp1 { + opp-level = <16>; + }; + + rpmpd_opp_ret: opp2 { + opp-level = <64>; + }; + + rpmpd_opp_svs: opp3 { + opp-level = <256>; + }; + }; + }; + + child4: consumer@12341000 { + compatible = "foo,consumer"; + reg = <0x12341000 0x1000>; + power-domains = <&parent4>, <&parent5>; + assigned-performance-states = <0>, <256>; + };
While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains. Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org> --- .../bindings/power/power-domain.yaml | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+)