Re: [RFC][PATCH 1/1] OMAP: voltage: add a hook for normal regulator calls

[Kevin Hilman <khilman@ti.com>]

"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:

> On Tue, Dec 06, 2011 at 00:37:38, Hilman, Kevin wrote:
> [...]
>> >
>> > We want to use the existing OMAP implementation of cpufreq (and DVFS) on 
>> > the devices which do not have VC/VP.
>> >
>> > The current OMAP cpufreq code under drivers/ invokes clk_set_rate().
>> >
>> > We had a look at the future DVFS implementation for OMAP[1] and merged in 
>> > the relevant patches (hope this is close to what's planned).
>> 
>> Unfortunately, that implementation is not what's planned, and in fact
>> was rejected some time ago.
>
> That's really unfortunate :(
>
>> 
>> > After this change, cpufreq invokes omap_device_scale(). The DVFS code
>> > makes use of the OPP layer and adds a request for voltage and frequency
>> > change. However, the voltage change request expects the scaling to be done
>> > in scaling functions defined in the voltage layer (vc->scale or vp->scale)
>> >
>> > On devices which do not have VC/VP, instead of just hacking the current
>> > implementation to get the voltage scaling done, we thought of adding
>> > a separate path.
>> 
>> A much better path for SoCs without VC/VP is to simply modify the
>> CPUfreq driver to use the regulator API to scale voltage before calling
>> clk_set_rate() (if scaling up) and after scaling the frequency (if
>> scaling down.)
>
> I assume this needs to be done using the OPP library?

Yes, the mainline cpufreq driver (queued and merging for v3.3, see my
for_3.3/omap-cpufreq branch) already uses the OPP library to determine
frequencies.  From there, it's a small step to get the voltage
associated with the OPP and use the regulator framework to scale the
voltage.

>> 
>> In fact, that is the direction we're going for DVFS, even for VC/VP
>> platforms.  There will be a regulator driver which will call the
>> voltagedomain/VC/VP calls to scale the voltage when needed, so from a
>> DVFS perspective, you use the clock API to change frequency, and the
>> regulator API to change voltages.
>
> Wouldn't this end up adding OMAP specific code into the various regulator
> drivers? If TPS65910 gets used on a variant that has VC/VP, won't this
> require making changes in the regulator drivers to being with?

Yes.  Tero is working on this now for the TWL PMICs, and the additional
code is rather small.

>> 
>> This should be a much simpler approach for you, and much easier to
>> understand.
>
> Yes, making calls to the regulator and clock frameworks is much simpler
> and desirable.

Great, I'm glad you agree.

Kevin