On 26-08-15, 13:06, Lee Jones wrote: > On Wed, 12 Aug 2015, Viresh Kumar wrote: > > > On 11-08-15, 16:17, Lee Jones wrote: > > > 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. I agree and can understand the pain you are feeling.. @Rob/Stephen: Please close this thread soon and let Lee get his work done :) -- viresh -- 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
