Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

[J, KEERTHY]

On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy@xxxxxx> wrote:
> On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman@xxxxxx> wrote:
>> 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/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.

Hello Kevin,

A gentle ping on this series. Any comments on this?

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



-- 
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/