linux-kernel - Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2012 09:55:26 +0530
From:	"J, KEERTHY" <j-keerthy@...com>
To:	Kevin Hilman <khilman@...com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	rjw@...k.pl, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org, j-pihet@...com
Subject: Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman@...com> wrote:
> Hi Mark,
>
> Mark Brown <broonie@...nsource.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
>
> [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

Thanks for the detailed answer Kevin.

-- 
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/