From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756844AbbHZMGi (ORCPT ); Wed, 26 Aug 2015 08:06:38 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:36199 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752228AbbHZMGf (ORCPT ); Wed, 26 Aug 2015 08:06:35 -0400 Date: Wed, 26 Aug 2015 13:06:28 +0100 From: Lee Jones To: Viresh Kumar Cc: Stephen Boyd , Rob Herring , Nishanth Menon , kernel@stlinux.com, "linux-pm@vger.kernel.org" , Dmitry Eremin-Solenikov , Rafael Wysocki , "linux-kernel@vger.kernel.org" , Sebastian Reichel , "devicetree@vger.kernel.org" , Arnd Bergmann , Ajit Pal Singh , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Message-ID: <20150826120628.GZ19409@x1> References: <20150810132247.GH3249@x1> <20150811080023.GB5509@linux> <20150811093039.GA18282@x1> <20150811100941.GG5509@linux> <20150811115425.GE18282@x1> <20150811120124.GH5509@linux> <20150811132756.GG18282@x1> <20150811142812.GJ5509@linux> <20150811151736.GO18282@x1> <20150812110841.GC20238@linux> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150812110841.GC20238@linux> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 , 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