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: <m2r30i4w35.fsf@baylibre.com>
Date:   Sun, 23 Apr 2017 15:07:10 -0700
From:   Kevin Hilman <khilman@...libre.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>, Nishanth Menon <nm@...com>,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
        Viresh Kumar <vireshk@...nel.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        linaro-kernel@...ts.linaro.org, rnayak@...eaurora.org,
        Stephen Boyd <sboyd@...eaurora.org>, lina.iyer@...aro.org
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

Viresh Kumar <viresh.kumar@...aro.org> writes:

> On 20-04-17, 10:43, Sudeep Holla wrote:
>> Just that the term performance is closely related to frequency, it needs
>> to be explicit on what *exactly* it means. As it stands now,
>> it can be used for OPP as I explain which controls both but as you
>> clarify that's not what it's designed for.
>
> We are talking about active states of a power domain here and
> *performance* is the best word I got.
>
> And yes we can still have
> frequency as a configurable here, just that current platforms don't
> have it.

It's not that your platforms don't have frequency, it's just that it's
hidden by firmware on an M3 in your particular case.

DT is meant to model hardware, and surely what the M3 is managing is
frequency and/or voltage (IOW, an OPP).

The way I see it, the problem you're trying to solve is complicated just
because you don't know the exat freq and/or voltage because they are
hiddent behind the firware, and all you have control over is an index.  

What if you drop the introduction of the new domain-performance-state
and just stick with OPPs (and phandles to them), and for cases where you
don't know the exact freq/volage pairs, just use indexes and comment
what they refer to:

operating-points = <
	/*
         * NOTE: actual frequency and voltages are managed by
         * firmware and are hidden from HLOS, so we simply use index
         * here to select the OPP
         */
        1 1
	2 2
	3 3
>;

Since selecting the OPP is up to the power-domain driver implementation,
this should be fine, IMO.

This would mean just updating the doc to reflect the "relaxing" of these
fields to reflect indexes in cases where the exact freq/voltages are not
known.

IMO, this would be much simpler, as it avoids adding a new property and
continues to use teriminology that people are already familiar with
around OPPs.

Kevin