On Wed, Jun 17, 2015 at 8:33 AM, Viresh Kumar [off-list ref] wrote:

On 17-06-15, 08:23, Rob Herring wrote:

quoted

quoted

+                       operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>;

You've made a fundamental change here in that this can now be a list
of phandles. There should be some description on what a list means
(merge the tables?, select one?).

Did you miss the description I wrote few lines earlier or are you
asking for something else? This is what I wrote earlier:

quoted

quoted

+Devices may want to choose OPP tables at runtime and so can provide a list of
+phandles here. But only *one* of them should be chosen at runtime.

So, clearly only ONE of the tables should be used.

Yes, never mind.

quoted

I think this needs to have a defined order and the platform should
know what that is. For example, if you read the efuses and decide you
need the "slow" table, you know to pick the first entry. Then you
don't need opp-name. Does that work for QCom?

Why forcing on the order here? For example, consider a case where the
platform can have four tables, A B C D. Now DT is free to pass all
four or just a subset of those. Like, for some boards table B doesn't
stand valid. And so it may wanna pass just A C D. And so keeping these
tables in order is going to break for sure. Flexibility is probably
better in this case.

Defined order is a key part of DT bindings. We solve the variable
length problem with name lists associated with variable length
property like:

operating-point-names = "slow", "fast";

I'm not a fan of doing this if we can avoid it, but we should at least
follow the same pattern. Don't send me a patch with that yet, I want
to hear from Stephen.

You can also use "status" to disable specific tables rather than
removing from the list.

Rob