Subject: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

From: [email-masked] (Kevin Hilman)
Date: Fri, 27 Apr 2012 14:01:17 -0700

Hi Mark,

Mark Brown <[email-masked]> writes:

> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>
>> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>> pre defined Operating Performance Points or the OPPs. Every OPP being
>> a voltage/frequency pair. Smartreflex is a different
>> power management technique.
>
> But presumably these things should integrate somehow - for example,
> should devfreq and cpufreq be providing inputs into what AVS is doing,
> and if so how?

The way it is currently designed, cpufreq/devfreq/regulator layers don't
need to know about AVS.

The higher-level layers only know about the "nominal" voltage.  AVS
hardware does automatic, adaptive, micro-adjustments around that nominal
voltage, and these micro-adjustments are managed by the AVS hardware
sending commands to the PMIC.  (specifically, on OMAP, the AVS sensors
provide inputs to the voltage processor (VP) which provide inputs to the
voltage controller (VC) which sends commands to the PMIC[1].)

The driver proposed here is primarily for initializing the various
parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
adjustments are done in hardware by VC/VP.

The only thing the higher-level layers might potentially need to do to
enable/disable AVS around transitions (e.g. when changing OPP, AVS is
disabled before changing OPP and only re-enabled when the new nominal
voltage has been acheived.)

On OMAP, we handle this inside the OMAP-specific voltage layer which is
called by the regulator framework, so even the regulators do not need
any knowledge of AVS.

Kevin

[1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a 
    detailed diagram:
    http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip