linux-kernel - Re: [linux-pm] [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:	Tue, 08 May 2012 15:16:36 -0700
From:	Kevin Hilman <khilman@...com>
To:	"Woodruff\, Richard" <r-woodruff2@...com>
Cc:	"AnilKumar\, Chimata" <anilkumar@...com>,
	"J\, KEERTHY" <j-keerthy@...com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm\@lists.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	"linux-omap\@vger.kernel.org" <linux-omap@...r.kernel.org>,
	"Pihet-XID\, Jean" <j-pihet@...com>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

"Woodruff, Richard" <r-woodruff2@...com> writes:

>> > >> The only thing the higher-level layers might potentially need to
>> > >> do is 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.)
>
> Getting clean baseline in place is huge step but actual production
> interfaces will need to comprehend some OPP to AVS dependencies beyond
> on/off.

A basic OMAP AVS driver has been in mainline for a long time, yet we
have not seen support submitted for all of these features.

When folks are motivated to propose such changes upstream, we will be
happy to discuss them and add support for them to the AVS driver.

Until then, the primary purpose of this series is to do some minimal
cleanup of an *existing* driver so it can be moved into drivers/*.  New
features can be added there as easily as they could've been added when
it was a driver under arch/arm.

Kevin

--
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/