Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

[Sudeep Holla <sudeep.holla@arm.com>]

On 28/04/17 06:00, Viresh Kumar wrote:
> On 27-04-17, 16:20, Rajendra Nayak wrote:
>>
>> On 04/27/2017 03:12 PM, Sudeep Holla wrote:
>> []..
>>
>>>>
>>>>> At qualcomm, we have an external M3 core (running its own firmware) which controls
>>>>> a few voltage rails (including AVS on those). The devices vote for the voltage levels
>>>
>>> Thanks for explicitly mentioning this, but ...
>>>
>>>>> (or performance levels) they need by passing an integer value to the M3 (not actual
>>>
>>> you contradict here, is it just voltage or performance(i.e. frequency)
>>> or both ? We need clarity there to choose the right representation.
>>
>> Its just voltage.
> 
> Right. Its just voltage in this case, but we can't speak of future
> platforms here and we have to consider this thing as an operating
> performance point only. I still think that this thread is moving in
> the right direction, specially after V6 which looks much better.
> 

Just thinking out loud, I can see platforms with have OPPs can move to
this binding in future eliminating the need to specify the clock and
regulators explicitly. So, I am not saying I against this idea, but I
see it might complicate the above case in terms of the precedence that
we consider in DT from backward compatibility.

E.g. if you now use this for just regulators, then I assume you continue
to use clocks. However, that makes it difficult for platforms
implementing *real* OPPs to reuse this binding as they may expect to
skip clock altogether.

Also we may need OPPs(both volt/freq), voltage only and clock only
bindings though all 3 are driven by the firmware and all are at abstract
levels. I am trying to broaden the scope now without having to churn
this binding again in near future.

So I don't totally agree that voltage regulators much have *real*
voltages and not abstract scale. Yes the correct bindings might have
such restrictions but can't we extend it ?

Anyways these are just my opinion.

> If we have anything strong against the way V6 is trying to solve it, I
> want to talk about it right now and get inputs from all the parties
> involved. Scrapping all this work is fine, but I would like to do it
> ASAP in that case :)
> 

As I said I am not against it, but I see it useful for a different
use-case, just not the one you are trying to solve here ;)

-- 
Regards,
Sudeep