lkml.org 
[lkml]   [2017]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From
Date


On 20/04/17 09:23, Ulf Hansson wrote:
> Viresh, Sudeep,
>
> Sorry for jumping in late.
>
> [...]
>
>>> On the contrary(playing devil's advocate here), we can treat all
>>> existing regulators alone as OPP then if you strip the voltages and
>>> treat it as abstract number.
>>
>> But then we are going to have lots of platform specific code which
>> will program the actual hardware, etc. Which is all handled by the
>> regulator framework. Also note that the regulator core selects the
>> common voltage selected by all the children, while we want to select
>> the highest performance point here.
>
> If I understand correctly, Sudeep is not convinced that this is about
> PM domain regulator(s), right?
>

No, I am saying that it has to be modeled as regulators or some kind of
advanced regulators. I am against modeling it as some new feature and
using similar terminology that are quite close to OPP/CPPC in which case
it's quite hard not to misunderstand the concepts and eventually use
these bindings incorrectly.

> To me there is no doubt, these regulators is exactly the definition of
> PM domain regulators.
>

+1

> That said, long time ago we have decided PM domain regulator shall be
> modeled as exactly that. From DT point of view, this means the handle
> to the PM domain regulator belongs in the node of the PM domain
> controller - and not in each device's node of those belonging to the
> PM domain.
>
> Isn't that what this discussion really boils down to? Or maybe I am
> not getting it.
>

I completely agree with you on all the above points. I am against the
performance state terminology. Since the regulators and OPP are already
defined in the bindings, all we need to explicitly state(if not already)
is that there are hierarchical.

--
Regards,
Sudeep

\
 
 \ /
  Last update: 2017-04-20 11:51    [W:0.133 / U:1.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site