On 07/31/2013 02:13 PM, Nishanth Menon wrote:
[...]
Unless we have two "phandles", we wont be able to do the same. Then
you'd want to standardize how we do that which is why I made the
proposal.
Let me try a slightly detailed proposal of what I am trying to suggest:
Usage option #1:
Legacy support.
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
};
Usage option #2:
Maintain only deltas in options from a base.
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points-names = "base", "high-performance";
operating-points-0 = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
operating-points-1 = <
/* kHz uV */
1000000 1200000
>;
};
Usage option #3: (not compatible definition to #2)
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points-names = "default", "high-performance";
operating-points-0 = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
operating-points-1 = <
/* kHz uV */
1000000 1200000
792000 1100000
396000 950000
198000 850000
>;
};
Usage option #4 (along with option 3 or 2):
cpu@1 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points-device = <&cpu0 high-performance>;
};
Usage option #5 (along with option 1):
This is the step we are attempting to do in this patch as far as I
understand.
cpu@1 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points-device = <&cpu0>;
};
board file override option:
&cpu0 {
operating-points-select = "default";
}
This will prevent selection of high-performance even if efuse is set
etc.. or force selection of high-performance independent of what efuse says.
This allows us:
a) To maintain dts in a separate repository without being dependent on
frequencies in kernel code for opp_enable/disable.
b) reasonably proceed towards complete SoC entitlement
c) not have to deal with multiple OPP definitions per board file.
Does that make sense? or do we see concerns?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
