From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965254AbbHKPRq (ORCPT ); Tue, 11 Aug 2015 11:17:46 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:32954 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965093AbbHKPRm (ORCPT ); Tue, 11 Aug 2015 11:17:42 -0400 Date: Tue, 11 Aug 2015 16:17:36 +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: <20150811151736.GO18282@x1> References: <20150731163715.GV3159@codeaurora.org> <20150803034642.GV899@linux> <20150810132247.GH3249@x1> <20150811080023.GB5509@linux> <20150811093039.GA18282@x1> <20150811100941.GG5509@linux> <20150811115425.GE18282@x1> <20150811120124.GH5509@linux> <20150811132756.GG18282@x1> <20150811142812.GJ5509@linux> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150811142812.GJ5509@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 Tue, 11 Aug 2015, Viresh Kumar wrote: > On 11-08-15, 14:27, Lee Jones wrote: > > Okay, so what you're saying is that you've already made the decision > > to create a separate node for every OPP permutation, > > Absolutely not. > > > despite the fact > > that I've told you this could lead to more nodes than anyone would > > care to successfully write or maintain? > > I have enough fear of yours and then I have to see you in another > month as well. I wouldn't dare to disobey your command SIR :) Funny guy! ;) > > Perhaps an example might help explain the issue. > > > > Using the current driver, we need to place the following in DT and the > > driver does the rest: > > > > opp-list { > > opp1 { > > opp-hz = <1500000000>; > > st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > st,substrate = <0xff>; > > st,cuts = <0xff>; > > }; > > opp0 { > > opp-hz = <1200000000>; > > st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > st,substrate = <0xff>; > > st,cuts = <0x2>; > > }; > > }; > > Nothing is fixed as of now but this is what I am thinking of: > > cpu0_opp_table: opp_table0 { > compatible = "operating-points-v2"; > opp-cuts = "10", "3c", "f0"; > supply-names = "vcc0", "vcc1", "vcc2"; > opp-shared; > > opp00 { > opp-hz = /bits/ 64 <1000000000>; > clock-latency-ns = <300000>; > opp-microvolt-10 = <970000>; > opp-microvolt-3c = <950000>; > opp-microvolt-f0 = <930000>; > }; > > /* OR */ > > opp00 { > opp-hz = /bits/ 64 <1000000000>; > clock-latency-ns = <300000>; > opp-microvolt = <970000>, <950000>, <930000>; > }; > }; > > And then the platform code needs to tell OPP layer: > "Use OPPs for cut f0 for device X", and OPP layer will store that > somewhere. > > And then it will only initialize OPPs after matching this string with > the values. > > Out of the earlier two options, I may prefer the first one. As we will > be soon adding support for multiple regulators, and a single regulator > can have min/max/target values.. So, a single list will become too > long. 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? > But, something like this should be generic enough to capture most of > the cases. > > @Stephen/Rob ?? > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog