On 07/30, Rob Herring wrote:

On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones [off-list ref] wrote:

quoted

There is nothing stopping us from representing the data in this way.
On the plus side, it would mean that we wouldn't need any vendor
specific properties.  However, far outweighing the positives are the
fact that, even in our very simple example provided, where we only
have 2 frequencies, differ between only 1 cut and support all
substrates, we would still need 16 OPP tables.  When any one of those
variables increase (and they will), we would then have a large number
of permutations and subsequently and unruly amount of OPP tables.

(... and we haven't even provided the body-biasing information yet.)

The way we've chosen to represent our circumstance is the least
intrusive and the most succinct way we can think of.  Which IMHO
outweighs the fact that we have to introduce a couple of vendor
properties by a country mile.

Regardless of which is better or worse, you are both doing essentially
the same thing. You are selecting OPPs based on some Si parameters. We
should not really be doing this 2 different ways. I'd be fine with 2
ways if it was 2 for all SOCs, but right now it is 2 for 2 SOCs.
Really, I'd like to see most if not all the selection or fixup of OPPs
be done in the bootloader and the kernel just deals with the correct
OPP table.

Where are you storing the data that gets selected to fill into these
properties? Is it just look-up tables or is there some kind of
algorithm to generate the values? If the former, then DT is as good a
data struct as any to store the tables. There is a lot of duplication
though with only a single property varying in each set. If you both
have that problem, then perhaps we can come up with a generic way to
list all possible values more concisely.

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.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project