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. > > + > > +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 -- 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
