Messages in this thread | | | Subject | Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property | From | Rajendra Nayak <> | Date | Mon, 18 Jan 2021 11:09:40 +0530 |
| |
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)
-- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
| |