Re: [PATCH V6 1/3] OPP: Add new bindings to address shortcomings of existing bindings

On 02-06-15, 11:31, Stephen Boyd wrote:

Also, is there already code written to handle these new
bindings in the OPP library? If not, it would be good to write
some to flush out any problems that may be lurking in actual
implementation.

I had written code earlier for V2 or something, but then we went back
to the improvements in bindings and I stopped writing code for it.

http://marc.info/?i=cover.1423642246.git.viresh.kumar%40linaro.org

But that just requires to be updated a bit now. Will do that once I am
sure the bindings are all good now, with all Acks and RBYs.

quoted

+
+Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
+
+/ {
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&L2>;
+			clocks = <&clk_controller 0>;
+			clock-names = "cpu";
+			opp-supply = <&cpu_supply0>;

opp-supply isn't mentioned anywhere. Is that intentional? Is it

This should have been 'cpu-supply' instead.

supposed to be cpu-supply still?

Yes.

It isn't clear to me from the
previous discussion where this all ended up, but I'm not sure how
the in-kernel API is going to match up regulators with OPPs. I
mean, how are we going to ask the OPP library what the
min/max/target voltage is at a particular frequency when we have
multiple regulators? Is that some string based interface? 

	dev_pm_opp_get_voltage(name, &target, &min, &max);

Or a regulator pointer interface?

	dev_pm_opp_get_voltage(regulator, &target, &min, &max);

Probably this.

Or something else? Does this mean the OPP library is going to get
the CPU device to request the opp-supply from the CPU node?

Maybe yes. That will clarify more with more code in place.

Furthermore, why don't we care about opp-clocks? Are clocks
somehow special?

There shouldn't be opp-supply in the first place and so no need of
opp-clocks as well.

-- 
viresh