[PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT

[Rob Herring]

On Fri, Jun 19, 2015 at 1:47 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> On 06/18, Viresh Kumar wrote:
>> On 18-06-15, 07:55, Viresh Kumar wrote:
>> > Why do you think so? For me the operating-points-v2-names property
>> > will be present in CPU node (as there is no OPP node which can have
>> > it) and so every CPU is free to choose what it wants to.
>>
>> So, I had something like this in mind:
>>
>> From: Viresh Kumar <viresh.kumar at linaro.org>
>> Date: Thu, 30 Apr 2015 17:38:00 +0530
>> Subject: [PATCH] OPP: Allow multiple OPP tables to be passed via DT
>>
>> 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 prom) and knowing characteristics of the SoC.
>>
>> 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 operating-points-v2 bindings to support that.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
>
> Looks mostly ok..
>
>> ---
>>  Documentation/devicetree/bindings/power/opp.txt | 63 +++++++++++++++++++++++++
>>  1 file changed, 63 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
>> index 259bf00edf7d..72ccacaac9c9 100644
>> --- a/Documentation/devicetree/bindings/power/opp.txt
>> +++ b/Documentation/devicetree/bindings/power/opp.txt
>> @@ -45,10 +45,21 @@ Devices supporting OPPs must set their "operating-points-v2" property with
>>  phandle to a OPP table 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. This must be
>> +accompanied by a corresponding "operating-points-v2-names" property, to uniquely
>> +identify the OPP tables.
>> +
>>  If required, this can be extended for SoC vendor specfic bindings. Such bindings
>>  should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
>>  and should have a compatible description like: "operating-points-v2-<vendor>".
>>
>> +Optional properties:
>> +- operating-points-v2-names: Names of OPP tables (required if multiple OPP

Let's drop v2. We know it only applies to v2.

>> +  tables are present), to uniquely identify them. The same list must be present
>> +  for all the CPUs which are sharing clock/voltage rails and hence the OPP
>> +  tables.
>> +
>>  * OPP Table Node
>>
>>  This describes the OPPs belonging to a device. This node can have following
>> @@ -63,11 +74,16 @@ 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.
>> +
>
> But isn't this being removed? If it is removed, feel free to add
>
> Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>

Same question here.

Acked-by: Rob Herring <robh at kernel.org>

Rob