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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af22ce1e-cd71-6b5e-8fd6-98e73438da9f@arm.com>
Date:   Thu, 20 Apr 2017 10:51:27 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Kevin Hilman <khilman@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linaro-kernel <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Lina Iyer <lina.iyer@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for
 power-domains



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