On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: > Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 :) 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.
Attachment:
signature.asc
Description: Digital signature
