On 10/30, Viresh Kumar wrote:
> + opp_table {
> + compatible = "operating-points-v2";
> + status = "okay";
> + opp-shared;
> +
> + opp00 {
A side-note. I wonder if it would be better style to have the
node name be:
opp@600000000 {
At least it seems that the assumption is we can store all the
possible combinations of OPP values for a particular frequency in
the same node. Following this style would make dt compilation
fail if two nodes have the same frequency.
Also, this makes it sound like opp-supported-hw is really just
telling us if this is a supported frequency or not for the
particular device we're running on. The current wording makes it
sound like we could have two OPP nodes with the same frequency
but different voltages inside them, which we're trying to
discourage by compressing the tables into less nodes.
I think in Lee's case we're only going to use the cuts parameter
to figure out if the OPP is supported or not. On qcom platforms
we will only use one parameter for this property as well, the
speed bin. The slow/fast and version stuff will be handled by
named opp properties.
> + /*
> + * Supports all substrate and process versions for 0xF
> + * cuts, i.e. only first four cuts.
> + */
> + opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>
> + opp-hz = /bits/ 64 <600000000>;
> + opp-microvolt = <900000 915000 925000>;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
