Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
From: Lee Jones
Date: Mon Aug 10 2015 - 09:23:04 EST
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
> - 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/