On Wed, 12 Aug 2015, Viresh Kumar wrote:

On 11-08-15, 16:17, Lee Jones wrote:

quoted

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?

'pcode', 'cut' and 'substrate' all determine whether a given set of
OPPs an be used on the running platform.  I do not believe that you
can differentiate between them. 

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

If it makes it easier, you can treat them as version numbers 2.2.1
<pcode.cut.substrate>, but I don't see how this can help.  Obviously
this becomes more difficult when you add wild cards to the OPPs, where
a particular OPP would be suitable for all cuts for example.

If you still think you can come up with a generic method to lay out
CPUFreq OPP nodes that will satisfy all vendors and not be a mass of
10's of separate nodes, then great.  Again, I'm struggling to see how
that might be possible.

What I believe we shouldn't do, is have this blocked forever for the
sake of adding a couple of vendor properties however.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog