Thread (16 messages) 16 messages, 6 authors, 2021-06-18

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: 2021-06-01 11:44:32
Also in: linux-arm-msm, linux-pm, lkml

On 01-06-21, 13:12, Stephan Gerhold wrote:
quoted
+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };
Bjorn already asked this in v1 [1]:
quoted
May I ask how this is different from saying something like:

	required-opps = <&??>, <&rpmpd_opp_svs>;
and maybe this was already discussed further elsewhere. But I think at
the very least we need some clarification in the commit message + the
binding documentation how your new property relates to the existing
"required-opps" binding.

Because even if it might not be implemented at the moment,
Documentation/devicetree/bindings/power/power_domain.txt actually also
specifies "required-opps" for device nodes e.g. with the following example:

	leaky-device0@12350000 {
		compatible = "foo,i-leak-current";
		reg = <0x12350000 0x1000>;
		power-domains = <&power 0>;
		required-opps = <&domain0_opp_0>;
	};

It looks like Viresh added that in commit e856f078bcf1
("OPP: Introduce "required-opp" property").

And in general I think it's a bit inconsistent that we usually refer to
performance states with phandles into the OPP table, but the
assigned-performance-states suddenly use "raw numbers".
I must have missed that discussion, sorry about that.

The required-opps property, when present in device's node directly, is about the
(default) OPPs to choose for that device's normal functioning as they may not do
DVFS.

Good point Stephan.

-- 
viresh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help