From: Kevin Hilman <khilman@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "J\, KEERTHY" <j-keerthy@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@sisk.pl, linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, j-pihet@ti.com,
durgadoss.r@intel.com
Subject: Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Date: Mon, 30 Apr 2012 14:51:48 -0700 [thread overview]
Message-ID: <87wr4wriq3.fsf@ti.com> (raw)
In-Reply-To: <20120430095429.GB3170@opensource.wolfsonmicro.com> (Mark Brown's message of "Mon, 30 Apr 2012 10:54:29 +0100")
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
> 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.
next prev parent reply other threads:[~2012-04-30 21:51 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 17:40 [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) Keerthy
2012-04-26 17:40 ` [PATCH V3 01/10] ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power Keerthy
2012-04-26 17:40 ` [PATCH V3 02/10] ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr * Keerthy
2012-04-26 17:40 ` [PATCH V3 03/10] ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains Keerthy
2012-04-26 17:40 ` [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries Keerthy
2012-05-04 8:30 ` AnilKumar, Chimata
2012-05-04 10:11 ` J, KEERTHY
2012-05-07 23:39 ` Kevin Hilman
2012-05-07 23:55 ` Kevin Hilman
2012-05-08 3:44 ` J, KEERTHY
2012-04-26 17:40 ` [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro Keerthy
2012-05-04 9:12 ` AnilKumar, Chimata
2012-05-07 5:21 ` J, KEERTHY
2012-05-08 10:17 ` AnilKumar, Chimata
2012-05-10 6:19 ` J, KEERTHY
2012-04-26 17:40 ` [PATCH V3 06/10] ARM: OMAP2+: Voltage: Move the omap_volt_data structure to plat Keerthy
2012-04-26 17:40 ` [PATCH V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data structure Keerthy
2012-05-10 19:11 ` Guyotte, Greg
2012-05-11 3:51 ` J, KEERTHY
2012-04-26 17:40 ` [PATCH V3 08/10] ARM: OMAP2+: SmartReflex: Create per-opp debugfs node for errminlimit Keerthy
2012-04-26 17:40 ` [PATCH V3 09/10] ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options Keerthy
2012-04-26 17:40 ` [PATCH V3 10/10] ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/ Keerthy
2012-04-26 19:11 ` [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) Mark Brown
2012-04-27 5:39 ` J, KEERTHY
2012-04-27 17:56 ` Mark Brown
2012-04-27 21:01 ` Kevin Hilman
2012-04-30 4:25 ` J, KEERTHY
2012-04-30 9:54 ` Mark Brown
2012-04-30 21:51 ` Kevin Hilman [this message]
2012-05-02 5:04 ` J, KEERTHY
2012-05-04 5:05 ` J, KEERTHY
2012-05-04 8:21 ` AnilKumar, Chimata
2012-05-07 23:48 ` Kevin Hilman
2012-05-08 3:48 ` J, KEERTHY
2012-05-08 10:17 ` AnilKumar, Chimata
2012-05-08 20:38 ` Woodruff, Richard
2012-05-08 22:16 ` [linux-pm] " Kevin Hilman
2012-05-09 0:39 ` Woodruff, Richard
2012-05-09 8:19 ` Koen Kooi
2012-05-09 18:29 ` Kevin Hilman
2012-05-23 13:27 ` Menon, Nishanth
2012-05-24 23:16 ` Kevin Hilman
2012-05-07 23:51 ` Kevin Hilman
2012-05-15 5:46 ` J, KEERTHY
2012-05-23 4:51 ` J, KEERTHY
2012-05-24 17:24 ` Kevin Hilman
2012-05-31 22:40 ` Kevin Hilman
2012-06-01 3:45 ` J, KEERTHY
2012-04-26 18:05 Keerthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wr4wriq3.fsf@ti.com \
--to=khilman@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=durgadoss.r@intel.com \
--cc=j-keerthy@ti.com \
--cc=j-pihet@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).