On 05/08/2017 09:45 AM, Viresh Kumar wrote:
On 06-05-17, 11:58, Kevin Hilman wrote:
Rob Herring robh@kernel.org writes:
On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote:
Power-domains need to express their active states in DT and the devices within the power-domain need to express their dependency on those active states. The power-domains can use the OPP tables without any modifications to the bindings.
Add a new property "power-domain-opp", which will contain phandle to the OPP node of the parent power domain. This is required for devices which have dependency on the configured active state of the power domain for their working.
For some platforms the actual frequency and voltages of the power domains are managed by the firmware and are so hidden from the high level operating system. The "opp-hz" property is relaxed a bit to contain indexes instead of actual frequency values to support such platforms.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Documentation/devicetree/bindings/opp/opp.txt | 74 ++++++++++++++++++++++++++- 1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 63725498bd20..6e30cae2a936 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -77,7 +77,10 @@ This defines voltage-current-frequency combinations along with other related properties. Required properties: -- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. In some
- cases the exact frequency in Hz may be hidden from the OS by the firmware and
- this field may contain values that represent the frequency in a firmware
- dependent way, for example an index of an array in the firmware.
Not really sure OPP binding makes sense here.
I think OPP makes perfect sense here, because microcontroller firmware is managaging OPPs in hardware. We just may not know the exact voltage and/or frequency (and the firmware/hardware may even be doing AVS for micro-adjustments.)
Yes, AVS is being done for the Qcom SoC as well.
What about all the other properties. We expose voltage, but not freq?
I had the same question. Seems the same comment about an abstract "index" is needed for voltage also.
Why should we do that? Here are the cases that I had in mind while writing this:
DT only contains the performance-index and nothing else (i.e. voltages aren't exposed).
We wouldn't be required to fill the microvolt property as it is optional.
So the performance-index is specified in opp-hz property? What if the microcontroller firmware maps the performance-index to voltage but expects linux to scale the frequency? There is no way to specify a performance-index *and* a frequency for a OPP now I guess?
DT contains both performance-index and voltages.
The microvolts property will contain the actual voltages and opp-hz will contain the index.
So this is for cases where the performance-index maps to a freq managed by the microcontroller and voltages managed by linux? I have a case of exact opposite and I don't see now how to handle it now with these bindings.
I don't see why would we like to put some index value in the microvolts property. We are setting the index value in the opp-hz property to avoid adding extra fields and making sure opp-hz is still the unique property for the nodes.
Maybe to handle the case like what I described above?