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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
