Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones <lee.jones@linaro.org>]

On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 12:54, Lee Jones wrote:
> > The framework does not need to parse this information.  It is used
> > solely by the platform driver, whose job it is to decide which OPPs
> > are appropriate for the running platform.
> 
> The OPP layer needs to parse OPP nodes in DT. But for doing that it
> needs to know which OPPs to pick from the table as, in cases like
> yours or qcom, not all OPPs might be available.
> 
> One of the ways to do that is:
> - the platform reads its efuses (or whatever) and encodes the
>   information into a string.
> - This string should match with the strings present (somewhere) in the
>   OPP table. That location can be like what I proposed few mails back.
> - Then the *generic* OPP code can parse only those OPP nodes which
>   match with that string.
> 
> This way, we can avoid pushing the platform code to parse OPP tables.

Okay, so what you're saying is that you've already made the decision
to create a separate node for every OPP permutation, despite the fact
that I've told you this could lead to more nodes than anyone would
care to successfully write or maintain?

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>;
	};
};

However, what you're suggesting, even for this very simple example
(imagine what this would look like with 5 or more frequencies where
two or more of them were only appropriate to run on particular
variants) requires this to be broken out to:

opp-list {
	pcode0-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1110000>;
		};
	};

	pcode0-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1200000>;
		};
	};

	pcode1-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1150000>;
		};
	};

	pcode1-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1200000>;
		};
	};

	pcode2-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1100000>;
		};
	};

	pcode2-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1200000>;
		};
	};

	pcode3-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1080000>;
		};
	};

	pcode3-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1200000>;
		};
	};

	pcode4-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1040000>;
		};

	pcode4-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1170000>;
		};
	};

	pcode5-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <1020000>;
		};
	};

	pcode5-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1140000>;
		};
	};

	pcode6-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <980000>;
		};
	};

	pcode6-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1100000>;
		};
	};

	pcode7-cut2-allsubstrates {
		opp0 {
			opp-hz = <1200000000>;
			opp-microvolt = <930000>;
		};
	};

	pcode7-allcuts-allsubstrates {
		opp0 {
			opp-hz = <1500000000>;
			opp-microvolt = <1070000>;
		};
	};
};


These will soon multiply once you start providing more complex
examples.  And how do you plan on handling this in the framework?  Can
the driver submit more than one variations of the string?  In the
current example the driver would need to submit four strings to
provide all acceptable variations; "pcodeX-cutY-substrateZ",
"pcodeX-allcuts-substrateZ", "pcodeX-cutY-allsubstrates" and
"pcodeX-allcuts-allsubstrates"

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog