Re: [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP

[Nishanth Menon <nm@ti.com>]

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