On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 14:27, Lee Jones wrote:
> > Okay, so what you're saying is that you've already made the decision
> > to create a separate node for every OPP permutation,
>
> Absolutely not.
>
> > despite the fact
> > that I've told you this could lead to more nodes than anyone would
> > care to successfully write or maintain?
>
> I have enough fear of yours and then I have to see you in another
> month as well. I wouldn't dare to disobey your command SIR :)
Funny guy! ;)
> > Perhaps an example might help explain the issue.
> >
> > Using the current driver, we need to place the following in DT and the
> > driver does the rest:
> >
> > opp-list {
> > opp1 {
> > opp-hz = <1500000000>;
> > st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>;
> > st,substrate = <0xff>;
> > st,cuts = <0xff>;
> > };
> > opp0 {
> > opp-hz = <1200000000>;
> > st,avs = <1110 1150 1100 1080 1040 1020 980 930>;
> > st,substrate = <0xff>;
> > st,cuts = <0x2>;
> > };
> > };
>
> Nothing is fixed as of now but this is what I am thinking of:
>
> cpu0_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> opp-cuts = "10", "3c", "f0";
> supply-names = "vcc0", "vcc1", "vcc2";
> opp-shared;
>
> opp00 {
> opp-hz = /bits/ 64 <1000000000>;
> clock-latency-ns = <300000>;
> opp-microvolt-10 = <970000>;
> opp-microvolt-3c = <950000>;
> opp-microvolt-f0 = <930000>;
> };
>
> /* OR */
>
> opp00 {
> opp-hz = /bits/ 64 <1000000000>;
> clock-latency-ns = <300000>;
> opp-microvolt = <970000>, <950000>, <930000>;
> };
> };
>
> And then the platform code needs to tell OPP layer:
> "Use OPPs for cut f0 for device X", and OPP layer will store that
> somewhere.
>
> And then it will only initialize OPPs after matching this string with
> the values.
>
> Out of the earlier two options, I may prefer the first one. As we will
> be soon adding support for multiple regulators, and a single regulator
> can have min/max/target values.. So, a single list will become too
> long.
This would work if we only had a single variable to contend with, but
what I showed you in my previous example is that we have 3 variables
to consider; cut (version), pcode and substrate.
Using the two (simple) examples I provided, how would your suggestion
look in our case?
> But, something like this should be generic enough to capture most of
> the cases.
>
> @Stephen/Rob ??
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
