On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <khilman@xxxxxx> 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/*. AnilKumar, The intent of the series as explained by Kevin if to do the necessary clean up for the driver to move from mach-omap to drivers/*. We will for sure need more enhancements for other classes support. > > Support for additional classes can be added after the driver is moved > if/when folks are motivated to post that support upstream. > >> The SR class 2B implementation on these devices does not exist in mainline. >> I can point to some public repositories if you are interested in taking a look at >> the current code. > > No thanks. We can discuss it when you post support for it to mainline. > > Kevin > >> Implementation of this SR method is must on at least the DM8168 device and >> I know some customers who are using it on their production systems. >> >> Regards >> AnilKumar >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- Regards and Thanks, Keerthy _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
