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
| ||
|
Date: Wed, 2 May 2012 10:34:29 +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, durgadoss.r@...el.com Subject: Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman@...com> wrote: > Mark Brown <broonie@...nsource.wolfsonmicro.com> writes: > >> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>> Mark Brown <broonie@...nsource.wolfsonmicro.com> writes: >> >>> > 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. >> >> Yes, and that was a part of my concern, but see below. >> >>> 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].) >> >> Right, that's what I'd understood it to be. >> >>> 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. >> >> It's not just a driver, though - it's also creating this power/avs >> thing, though now I look at the code rather than just its shape there's >> not actually an abstraction being added here, it's mostly just straight >> code motion of the arch/arm code that's there already. The changelog >> and the shape of the code make it sound like this is intended to be >> somewhat generic when really it's providing some OMAP specific tuning >> for the device which is much less of a concern. >> >> I guess for now it's probably OK to just clarify in the documentation >> and say that whoever adds the second driver has to work on making this >> generic :) > > Agreed. > > In a different thread (which I can't seem to find now) we discussed this > as well, so it just sounds like the changelog should clarify this a bit > better. Kevin/Mark, Thanks for the feedback. I will add more documentation to clarify this aspect. Please let me know if there are any more things to be taken care of in this patch set. > > Kevin > >> This does also sound rather like it's in a similar area to the current >> management work which Durgadoss R (CCed) was working on, though with a >> slightly different application and in the OMAP case it's pretty much all >> hidden in the external processor. > -- 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/
Powered by blists - more mailing lists