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@xxxxxxxxxxxxxx> --- .../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
