Hi Nishanth, Viresh
If I may add my 2 cents.
> 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 that the above approach is more appealing [*].
> > };
> >
> > 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.
I agree with Nishanth here, that point 1 (as described by Viresh at
[*]) is a more scalable approach.
>
> [...]
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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
