On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote: > "AnilKumar, Chimata" <anilkumar@xxxxxx> writes: > > > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: > >> Hi Mark, > >> > >> Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
