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. -- 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
