On 06/18, Viresh Kumar wrote:

On 17-06-15, 18:30, Stephen Boyd wrote:

quoted

An operating-point(s?)-names property seems ok... but doesn't that mean
that every CPU that uses the OPP has to have the same list of
operating-point-names?

Why do you think so? For me the operating-points-v2-names property
will be present in CPU node (as there is no OPP node which can have
it) and so every CPU is free to choose what it wants to.

Yes.

quoted

It would make sense to me if the operating points
were called something different depending on *which* CPU is using them,
but in this case the only name for the operating point is "slow" or
"fast", etc.

I am completely confused now. :)

As am I.

The problem you stated now was there with the current state of
bindings. The name is embedded into the OPP table node and so is fixed
for all the CPUs. Moving it to the CPU node will give all CPUs a
chance to name it whatever they want to. And the same list has to be
replicated to all CPUs sharing the clock rails.

Yes I don't see how the name will be different for any CPU, hence
my complaint/question about duplicate names in each CPU. I guess
it isn't any worse than clock-names though so I'm fine with it.

quoted

In reality we've assigned them names like speedX-binY-vZ so that we know
which speed bin, voltage bin, and version they're part of. Maybe OPP
node properties like qcom,speed-bin = <u32>, qcom,pvs-bin = <u32>, etc.
would be better?

Lets see, only if we can't get the generic stuff for this.

quoted

At the least, operating-points-names will be required on qcom platforms.
A fixed ordering known to the platform would mean that we know exactly
how many voltage bins and speed bins and how many voltage bins per speed
bin are used for a particular SoC, which we've avoided knowing so far.

What are we referring to fixed ordering? If we have both a list of
phandles to OPP tables and a list of names, they can be rearranged in
whatever fashion we want. Isn't it?

This is a reply to Rob's question about fixed ordering without a
names property. That's unlikely to work out for qcom chips.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in