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

[Viresh Kumar]

On 7 May 2015 at 11:22, Stephen Boyd <sboyd at codeaurora.org> 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..

- Now if uV is fixed, how is the target current controlled separately ?

- 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 ?

- And finally how exactly should we write this in bindings to make
it clear to all users ?

Thanks.

--
viresh

[1] http://en.wikipedia.org/wiki/Three-phase_electric_power