Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes: > 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 :) 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 > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
