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: <20170420052533.GF5436@vireshk-i7>
Date:   Thu, 20 Apr 2017 10:55:33 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     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, rnayak@...eaurora.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for
 power-domains

On 19-04-17, 14:58, Sudeep Holla wrote:
> On 19/04/17 12:47, Viresh Kumar wrote:
> > On 18-04-17, 17:01, Sudeep Holla wrote:
> >> Understood. I would incline towards reusing regulators we that's what is
> > 
> > It can be just a regulator, but it can be anything else as well. That
> > entity may have its own clock/volt/current tunables, etc.
> > 
> >> changed behind the scene. Calling this operating performance point
> >> is misleading and doesn't align well with existing specs/features.
> > 
> > Yeah, but there are no voltage levels available here and that doesn't
> > fit as a regulator then.
> > 
> 
> We can't dismiss just based on that. We do have systems where
> performance index is mapped to clocks though it may not be 1:1 mapping.
> I am not disagreeing here, just trying to understand it better.

@Stephen: Can you answer here please ?

> >> Understood. We have exactly same thing with SCPI but it controls both
> >> frequency and voltage referred as operating points. In general, this OPP
> >> terminology is used in SCPI/ACPI/SCMI specifications as both frequency
> >> and voltage control. I am bit worried that this binding might introduce
> >> confusions on the definitions. But it can be reworded/renamed easily if
> >> required.
> > 
> > Yeah, so far we have been looking at OPPs as freq-voltage pairs ONLY
> > and that is changing. I am not sure if it going in the wrong
> > direction really. Without frequency also it is an operating point for
> > the domain. Isn't it?
> > 
> 
> Yes, I completely agree. I am not saying the direction is wrong. I am
> saying it's confusing and binding needs to be more clear.

What exactly isn't clear? (Yeah, there had been lots of emails and I
want to know what improvements are you looking for).

> 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.

Even if we have to configure both clock and voltage for the power
domain using standard clk/regulator frameworks, OPP will work just
fine as it will do that then. So, its not that we are bypassing the
regulator framework here. It will be used if we have the voltages
available for the power-domain's performance states.

> So if the firmware handles more than just
> regulators, I agree.

I don't know the internals of that really.

> At the same time, I would have preferred firmware
> to even abstract the frequency like ACPI CPPC.

Frequency isn't required to be configured for the cases I know, but it
can be in future implementations.

> It would be good to get
> more information on what exactly that firmware handles.

@Stephen ?

> I am just more cautious here since we are designing generic bindings and
> changing generic code, we need to understand what that firmware supports
> and how it may evolve(so that we can maintain DT compatibility)

Sure, I am fine with more discussions on it :)

> I did a brief check and wanted to check if this is SMD/RPM regulators ?

Yes, Qcom calls the external core as Resource and Power manager (RPM).

-- 
viresh