Re: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux