Messages in this thread | | | Subject | Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains | From | Sudeep Holla <> | Date | Fri, 28 Apr 2017 10:44:41 +0100 |
| |
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
| |