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

[Kevin Hilman]

Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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