From mboxrd@z Thu Jan 1 00:00:00 1970 From: nm@ti.com (Nishanth Menon) Date: Tue, 12 May 2015 11:09:04 -0500 Subject: [PATCH V4 2/3] OPP: Allow multiple OPP tables to be passed via DT In-Reply-To: References: Message-ID: <555225A0.8050707@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > --- > 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 -- Regards, Nishanth Menon