On Wed, Jun 17, 2015 at 8:33 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 17-06-15, 08:23, Rob Herring wrote: >> > + 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: > >> > +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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
