[lkml]   [2012]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
    Mark Brown <> writes:

    > On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
    >> Mark Brown <> 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 :)


    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


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

     \ /
      Last update: 2012-05-01 00:21    [W:0.028 / U:29.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site