On Tue, May 13, 2014 at 10:40 PM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> On 14 May 2014 06:32, Thomas Abraham <ta.omasab@xxxxxxxxx> 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@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.
[...]
--
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
