From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings Date: Thu, 7 May 2015 14:30:16 -0700 Message-ID: <20150507213015.GB2455@codeaurora.org> References: <20150504121209.GM15510@sirena.org.uk> <20150505105714.GA22845@sirena.org.uk> <20150505171252.GI22845@sirena.org.uk> <20150507055231.GB32399@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Viresh Kumar Cc: Mark Brown , Rafael Wysocki , Rob Herring , Arnd Bergmann , Nishanth Menon , Mike Turquette , Linaro Kernel Mailman List , "linux-pm@vger.kernel.org" , Grant Likely , "olof@lixom.net" , Sudeep Holla , "devicetree@vger.kernel.org" , Viswanath Puttagunta , Lucas Stach , Thomas Petazzoni , "linux-arm-kernel@lists.infradead.org" , Thomas Abraham , Abhilash Kesavan , Kevin Hilman , santosh List-Id: devicetree@vger.kernel.org On 05/07, Viresh Kumar wrote: > On 7 May 2015 at 11:22, Stephen Boyd wrote: > > If you look at the cpufreq/clock/pmic code on our codeaurora.org > > tree you'll see that it's used to pass a value with uA units > > through the regulator_set_optimum_mode() API. The call to > > regulator_set_optimum_mode() is here[1], and the place where we > > parse the OPP table from DT is here[2]. My understanding is that > > with recent changes to the regulator framework, we would do a > > s/regulator_set_optimum_mode/regulator_set_load/ and things would > > otherwise be the same on the consumer side. On the regulator > > side, we would move the .get_optimum_mode op to .set_load instead > > of the hack where we write to the hardware in > > .get_optimum_mode[3]. > > > > So does that mean it corresponds to a limit, or a nominal > > constant draw value, or a value to regulator to? From what I can > > tell it's used to figure out how many phases to enable[4]. I > > suspect that means it's being used to figure out what value it > > should regulate to. In newer PMICs this is all done > > automatically, but at least for some of the PMICs we need to do > > it manually. > > By current phases, you probably meant [1], right ? > > Also what I couldn't understand is how are you controlling the > current here? > > - Is this a current only regulator ? Probably not as your code has > a uv value as well.. No. > > - Now if uV is fixed, how is the target current controlled separately ? uV is not fixed > > - Should we have a min/max/target value of this current ? Like what > we are doing for voltage. Or is this just the 'target' current ? I don't think so. It's just about setting the load through the regulator_set_load() API when this OPP is used. > > - And finally how exactly should we write this in bindings to make > it clear to all users ? > Let's take this up on my reply to Mark. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project