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

From: "AnilKumar, Chimata" <anilkumar@ti.com>
To: "Hilman, Kevin" <khilman@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"J, KEERTHY" <j-keerthy@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@lists.linux-foundation.org" 
	<linux-pm@lists.linux-foundation.org>,
	"Pihet-XID, Jean" <j-pihet@ti.com>
Subject: RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Date: Tue, 8 May 2012 10:17:44 +0000	[thread overview]
Message-ID: <331ABD5ECB02734CA317220B2BBEABC13E9B6681@DBDE01.ent.ti.com> (raw)
In-Reply-To: <87mx5jy2li.fsf@ti.com>

On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
> 
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >> 
> >> Mark Brown <broonie@opensource.wolfsonmicro.com> 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,
> >
> > I want to point out some cases of SR implementation where this may not
> > be true.
> >
> > Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.
> >
> > Under this, SR module issues an interrupt to ARM when there is a need to
> > change the voltage based on temperature changes, ageing etc.
> >
> > Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
> > The voltage change is a micro adjustment as in other SR classes.
> 
> That can easily be handled writing a plugin specific to class 2B.  This
> driver was designed so plugins for other classes can be supported.  
> 
> Sure, we might need some enhancements for other classes (we already know
> that we will for class 1 support.)  However, the purpose of this series
> is to do the cleanups necessary for the driver to move to drivers/*.
> 

It's perfectly fine with me. My intention was just to highlight that
class 2B SR will have to interact with regulator layer for voltage
changes, so I guess it is little different from other SR classes.

Thanks,
AnilKumar