Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1204260 > unrolled thread

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

Started byLee Jones <lee.jones@linaro.org>
First post2015-08-10 15:30 +0200
Last post2015-08-12 13:10 +0200
Articles 10 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-10 15:30 +0200
    Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-08-11 10:10 +0200
      Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-11 11:40 +0200
        Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-08-11 12:10 +0200
          Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-11 14:00 +0200
            Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-08-11 14:10 +0200
              Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-11 15:30 +0200
                Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-08-11 16:30 +0200
                  Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones <lee.jones@linaro.org> - 2015-08-11 17:20 +0200
                    Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Viresh Kumar <viresh.kumar@linaro.org> - 2015-08-12 13:10 +0200

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

FromLee Jones <lee.jones@linaro.org>
Date2015-08-10 15:30 +0200
SubjectRe: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Message-ID<pVVjl-7A8-29@gated-at.bofh.it>
On Mon, 03 Aug 2015, Viresh Kumar wrote:

> On 31-07-15, 09:37, Stephen Boyd wrote:
> > For qcom platforms, the frequency is almost always constant.
> > There may be some tables where we have a couple higher
> > frequencies than others because the speed bin is different.
> > Otherwise the voltage/current is changing based on the silicon
> > characteristics. So the biggest duplication is the frequency
> > property.
> > 
> > As far as I know there isn't any algorithm to generate the
> > voltage values. It's all hand tuned tables based on the silicon
> > characterization, so we're left to store these tables in DT and
> > pick the right one at runtime. With regards to the table
> > explosion, on qcom platforms we haven't worried that we have ~40
> > tables, but I'm not opposed to expressing it in a smaller set of
> > nodes, tables, etc. if that's what's desired.
> > 
> > Do we need vendor specific properties for that though? Or do we
> > need some sort of extended frequency/voltage properties that are
> > arrays of values that we can index into based on some silicon
> > characteristics? I like the name based approach because it's
> > simple. Use this OPP table because it's called
> > x-y-z-characteristics and be done. Cramming the tables into less
> > lines may save us some typing and dtb space, but I'm not sure
> > what else it does.
> 
> What about something like this:
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 0cb44dc21f97..bad7a8299b9c 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -74,6 +74,8 @@ This describes the OPPs belonging to a device. This node can have following
>    reference an OPP.
>  
>  Optional properties:
> +- opp-cuts: One or more strings, describing the versions of hardware the OPPs
> +  can support.

This isn't very generic.

I'm guessing some vendors my have quite a few ways to differentiate
between board versions/revisions/cuts etc.

How about another array where a vendor can choose to identify a piece
of hardware however they see fit.

Example 1 (simple version):

/* Version 1 */
opp-version = <1>;

Example 2 (using the kernel's versioning):

/* 2.6.32-rc1 */
opp-version = <2 6 32 1>;

Example 3 (using ST's versioning):

/* Major 2, Minor 0, Cut 2, All substrates */
opp-version = <2 0 2 0xff>;

Qcom (or anyone else wanting to use names to identify their revisions)
can continue to use their node name method, as it doesn't break any
convention.

>  - opp-shared: Indicates that device nodes using this OPP Table Node's phandle
>    switch their DVFS state together, i.e. they share clock/voltage/current lines.
>    Missing property means devices have independent clock/voltage/current lines,
> @@ -100,6 +102,9 @@ properties.
>    Entries for multiple regulators must be present in the same order as
>    regulators are specified in device's DT node.
>  
> +  If used with 'opp-cuts', then the number of entries present here must match
> +  the number of strings present in 'opp-cuts'.
> +
>  - opp-microamp: The maximum current drawn by the device in microamperes
>    considering system specific parameters (such as transients, process, aging,
>    maximum operating temperature range etc.) as necessary. This may be used to
> 

-- 
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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1204862

FromViresh Kumar <viresh.kumar@linaro.org>
Date2015-08-11 10:10 +0200
Message-ID<pWcNc-7FX-15@gated-at.bofh.it>
In reply to#1204260
On 10-08-15, 14:22, Lee Jones wrote:
> >  Optional properties:
> > +- opp-cuts: One or more strings, describing the versions of hardware the OPPs
> > +  can support.
> 
> This isn't very generic.
> 
> I'm guessing some vendors my have quite a few ways to differentiate
> between board versions/revisions/cuts etc.
> 
> How about another array where a vendor can choose to identify a piece
> of hardware however they see fit.
> 
> Example 1 (simple version):
> 
> /* Version 1 */
> opp-version = <1>;
> 
> Example 2 (using the kernel's versioning):
> 
> /* 2.6.32-rc1 */
> opp-version = <2 6 32 1>;
> 
> Example 3 (using ST's versioning):
> 
> /* Major 2, Minor 0, Cut 2, All substrates */
> opp-version = <2 0 2 0xff>;

But how will we parse this with generic code ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204920

FromLee Jones <lee.jones@linaro.org>
Date2015-08-11 11:40 +0200
Message-ID<pWeci-17Z-11@gated-at.bofh.it>
In reply to#1204862
On Tue, 11 Aug 2015, Viresh Kumar wrote:

> On 10-08-15, 14:22, Lee Jones wrote:
> > >  Optional properties:
> > > +- opp-cuts: One or more strings, describing the versions of hardware the OPPs
> > > +  can support.
> > 
> > This isn't very generic.
> > 
> > I'm guessing some vendors my have quite a few ways to differentiate
> > between board versions/revisions/cuts etc.
> > 
> > How about another array where a vendor can choose to identify a piece
> > of hardware however they see fit.
> > 
> > Example 1 (simple version):
> > 
> > /* Version 1 */
> > opp-version = <1>;
> > 
> > Example 2 (using the kernel's versioning):
> > 
> > /* 2.6.32-rc1 */
> > opp-version = <2 6 32 1>;
> > 
> > Example 3 (using ST's versioning):
> > 
> > /* Major 2, Minor 0, Cut 2, All substrates */
> > opp-version = <2 0 2 0xff>;
> 
> But how will we parse this with generic code ?

Why would you want to?

-- 
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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1204995

FromViresh Kumar <viresh.kumar@linaro.org>
Date2015-08-11 12:10 +0200
Message-ID<pWeFj-1Wr-5@gated-at.bofh.it>
In reply to#1204920
On 11-08-15, 10:30, Lee Jones wrote:
> On Tue, 11 Aug 2015, Viresh Kumar wrote:
> 
> > On 10-08-15, 14:22, Lee Jones wrote:
> > > >  Optional properties:
> > > > +- opp-cuts: One or more strings, describing the versions of hardware the OPPs
> > > > +  can support.
> > > 
> > > This isn't very generic.
> > > 
> > > I'm guessing some vendors my have quite a few ways to differentiate
> > > between board versions/revisions/cuts etc.
> > > 
> > > How about another array where a vendor can choose to identify a piece
> > > of hardware however they see fit.
> > > 
> > > Example 1 (simple version):
> > > 
> > > /* Version 1 */
> > > opp-version = <1>;
> > > 
> > > Example 2 (using the kernel's versioning):
> > > 
> > > /* 2.6.32-rc1 */
> > > opp-version = <2 6 32 1>;
> > > 
> > > Example 3 (using ST's versioning):
> > > 
> > > /* Major 2, Minor 0, Cut 2, All substrates */
> > > opp-version = <2 0 2 0xff>;
> > 
> > But how will we parse this with generic code ?
> 
> Why would you want to?

So that individual platforms don't need to reinvent the wheel ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205085

FromLee Jones <lee.jones@linaro.org>
Date2015-08-11 14:00 +0200
Message-ID<pWgnM-4co-3@gated-at.bofh.it>
In reply to#1204995
On Tue, 11 Aug 2015, Viresh Kumar wrote:
> On 11-08-15, 10:30, Lee Jones wrote:
> > On Tue, 11 Aug 2015, Viresh Kumar wrote:
> > 
> > > On 10-08-15, 14:22, Lee Jones wrote:
> > > > >  Optional properties:
> > > > > +- opp-cuts: One or more strings, describing the versions of hardware the OPPs
> > > > > +  can support.
> > > > 
> > > > This isn't very generic.
> > > > 
> > > > I'm guessing some vendors my have quite a few ways to differentiate
> > > > between board versions/revisions/cuts etc.
> > > > 
> > > > How about another array where a vendor can choose to identify a piece
> > > > of hardware however they see fit.
> > > > 
> > > > Example 1 (simple version):
> > > > 
> > > > /* Version 1 */
> > > > opp-version = <1>;
> > > > 
> > > > Example 2 (using the kernel's versioning):
> > > > 
> > > > /* 2.6.32-rc1 */
> > > > opp-version = <2 6 32 1>;
> > > > 
> > > > Example 3 (using ST's versioning):
> > > > 
> > > > /* Major 2, Minor 0, Cut 2, All substrates */
> > > > opp-version = <2 0 2 0xff>;
> > > 
> > > But how will we parse this with generic code ?
> > 
> > Why would you want to?
> 
> So that individual platforms don't need to reinvent the wheel ?

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.

Back to my question; how would you like arbitrary version information,
which means different things to different vendors to be used in
shared/generic/framework code?

-- 
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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205089

FromViresh Kumar <viresh.kumar@linaro.org>
Date2015-08-11 14:10 +0200
Message-ID<pWgxr-4D2-5@gated-at.bofh.it>
In reply to#1205085
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.

> Back to my question; how would you like arbitrary version information,
> which means different things to different vendors to be used in
> shared/generic/framework code?

Exactly like I wrote above. The platform just needs to give a string
that should match with the OPPs ..

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205134

FromLee Jones <lee.jones@linaro.org>
Date2015-08-11 15:30 +0200
Message-ID<pWhMR-6mR-9@gated-at.bofh.it>
In reply to#1205089
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205179

FromViresh Kumar <viresh.kumar@linaro.org>
Date2015-08-11 16:30 +0200
Message-ID<pWiIW-7IE-31@gated-at.bofh.it>
In reply to#1205134
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 :)

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

But, something like this should be generic enough to capture most of
the cases.

@Stephen/Rob ??

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205206

FromLee Jones <lee.jones@linaro.org>
Date2015-08-11 17:20 +0200
Message-ID<pWjvj-su-1@gated-at.bofh.it>
In reply to#1205179
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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205963

FromViresh Kumar <viresh.kumar@linaro.org>
Date2015-08-12 13:10 +0200
Message-ID<pWC4V-2z5-11@gated-at.bofh.it>
In reply to#1205206
On 11-08-15, 16:17, Lee Jones wrote:
> 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?

So the solution I gave is for picking the microvolt based on pcode.
The other two (cut, substrate) aren't about picking microvolt, but if
the OPP is available or not. Right?

If these terms are generic enough, then we can add something similar
to what you have added..

@Stephen ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web