On 07/30/2013 02:48 PM, Nishanth Menon wrote: > On 07/30/2013 01:34 PM, Stephen Warren wrote: >> On 07/30/2013 12:00 PM, Sudeep KarkadaNagesha wrote: >>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@xxxxxxx> >>> >>> If more than one similar devices share the same OPPs, currently we >>> need to replicate the OPP entries in all the nodes. >>> >>> Few drivers like cpufreq depend on physical cpu0 node to specify the >>> OPPs and only that node is referred irrespective of the logical cpu >>> accessing it. Alternatively to support cpuhotplug path, few drivers >>> parse all the cpu nodes for OPPs. Instead we can specify the phandle >>> of the node with which the current node shares the operating points. >>> >>> This patch adds support to specify the phandle in the operating points >>> of any device node, where the node specified by the phandle holds the >>> actual OPPs. >> >>> diff --git a/Documentation/devicetree/bindings/power/opp.txt >>> b/Documentation/devicetree/bindings/power/opp.txt >> >>> +Optional properties: >>> +- operating-points-phandle: phandle to the device node with which this >> >> That's a funny name. Bikeshedding a bit, how about >> shared-operating-points? >> >> I haven't thought at all about whether this change conceptually makes >> sense. >> > > They may not really be shared- we could have phandle list even. Well, they are shared, or you wouldn't have one node pointing at another node and hence sharing the same property... > one > might have optional OPP sets for a chip family that one may - I was > about to suggest something similar to pinctrl > > operating-points-names = "default", "performance", "cheapboard-config" ;) > operating-points-0 = <&...> > operating-points-1 = <&...> > operating-points-2 = <&...> There is an assertion that DT should only represent the absolute max limits for things like this, and not policy-oriented data such as different performance profiles. I don't expect you'll see anything like the above in DT, since it's more policy than HW description. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
