lkml.org 
[lkml]   [2012]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
    From
    On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman@ti.com> wrote:
    > Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
    >
    >> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
    >>> Mark Brown <broonie@opensource.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-05-02 07:41    [W:0.035 / U:0.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site