[PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree

[Nishanth Menon]

On Tue, May 13, 2014 at 10:40 PM, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> On 14 May 2014 06:32, Thomas Abraham <ta.omasab at gmail.com> wrote:
[...]
>> +#ifdef CONFIG_CPU_FREQ_BOOST_SW
>> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>
> Does this mean another block inside the cpu node ? Like this: ?
>
> cpu at 0 {
>         compatible = "arm,cortex-a9";
>         reg = <0>;
>         next-level-cache = <&L2>;
>         operating-points = <
>                 /* kHz    uV */
>                 792000  1100000
>                 396000  950000
>                 198000  850000
>         >;
>         boost-frequency = <
>                 792000
>                 198000
>         >;
> };
>
> I think it we might better add another field in the opp block as these
> OPPs are rather boost one..

If we change the meaning to be:
         operating-points = <
                 /* kHz    uV          boost? */
                 792000  1100000  1
                 396000  950000    0

We are adding a modifier to the OPP definition here and does imply
every platform which may or maynot require "boost" need to indicate
that - basically fails at least my "least common" description for a
generic definition. As I had indicated in other threads -> we are back
to the discussion of "additional properties" to an OPP..
Option 1:
  - describe modifiers separately (as in boost-frequencies) - that
operate based on data from opp table.
Option 2:
  - keep adding to the description of opp as time goes by - every SoC
has it's own set of quirks that are needed for an OPP - I know that at
TI, we have certain OPPs that can only be enabled *if* "custom
hardware driver" is enabled, and similar stories. - yet another
example is enable the OPP if efuse X, bit Y is set.

Personally, looking at the various descriptions and bL, cpu-idle
states dependencies on OPPs, etc.. Option 2 is a non-scalable
approach.

[...]