On 05/07, Viresh Kumar wrote: > On 7 May 2015 at 11:22, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> 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 -- 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
