On 04/30/2015 07:08 AM, Viresh Kumar wrote: > On some platforms (Like Qualcomm's SoCs), it is not decided until > runtime on what OPPs to use. The OPP tables can be fixed at compile > time, but which table to use is found out only after reading some efuses > (sort of an eeprom) and knowing characteristics of the SoC. they are more like prom than eeprom in many instances. > > To support such platform we need to pass multiple OPP tables per device > and hardware should be able to choose one and only one table out of > those. > > Update OPP-v2 bindings to support that. > > Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx> > --- > Documentation/devicetree/bindings/power/opp.txt | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt > index 3b67a5c8d965..07959903ec32 100644 > --- a/Documentation/devicetree/bindings/power/opp.txt > +++ b/Documentation/devicetree/bindings/power/opp.txt > @@ -14,6 +14,9 @@ Devices supporting OPPs must set their "operating-points-v2" property with > phandle to a OPP descriptor in their DT node. The OPP core will use this phandle > to find the operating points for the device. > > +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. > + > > * OPP Descriptor Node > > @@ -28,6 +31,8 @@ This describes the OPPs belonging to a device. This node can have following > reference an OPP. > > Optional properties: > +- opp-name: Name of the OPP table, to uniquely identify it if more than one OPP > + table is supplied in "operating-points-v2" property of device. > - shared-opp: Indicates that device nodes using this OPP descriptor's phandle > switch their DVFS state together, i.e. they share clock/voltage/current lines. > Missing property means devices have independent clock/voltage/current lines, > With some SoCs like AM335x - thanks to some brain dead incompatible hardware design choices, this might end up as a big list or various OPP tables. but overall, I must prefer this approach as well. Thanks for proposing this. will be great to see examples documented in bindings doc as well. With no further issues, Acked-by: Nishanth Menon <nm@xxxxxx> -- Regards, Nishanth Menon -- 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
