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]

Date:   Fri, 28 Apr 2017 10:44:41 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Rajendra Nayak <rnayak@...eaurora.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Mark Brown <broonie@...nel.org>,
        Rafael Wysocki <rjw@...ysocki.net>, ulf.hansson@...aro.org,
        Kevin Hilman <khilman@...aro.org>,
        Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>,
        robh+dt@...nel.org, lina.iyer@...aro.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for
 power-domains

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