Mailing List Archive: Linux: Kernel

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

Index | Next | Previous | View Threaded

j-keerthy at ti

Apr 26, 2012, 10:40 AM

Post #1 of 22 (235 views)
Permalink

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

From: J Keerthy <j-keerthy [at] ti>

AVS(Adaptive Voltage Scaling) is a power management technique which
controls the operating voltage of a device in order to optimize (i.e. reduce)
its power consumption. The voltage is adapted depending on static factors
(chip manufacturing process) and dynamic factors (temperature
depending performance).
The TI AVS solution is named Smartreflex.

To that end, create the AVS driver in drivers/power/avs and
move the OMAP SmartReflex code to the new directory. The
class driver is still retained in the mach-omap2 directory.

In preparation to the move of the OMAP code the following changes have been
made:
- fill in platform data from the device initialization code and pass
it to the driver,
- create CONFIG_AVS* config options accordingly.

The platform integration data for SmartReflex is passed from hwmod
and the voltage layer to the driver using pdata.

Tested on OMAP4430 SDP using omap2plus_defconfig with the
CONFIG_POWER_AVS* options set. Voltage correction seen
on oscilloscope on all three VDDs.
Based on master branch of the l-o git tree, commit
6bd61e8de0511dd9831eb9d89eea0b4603a10e9e.

Tree: git://gitorious.org/~keerthy05/omap-pm/keerthy-sr.git for_smartreflex_ip_driver_move

V3: rework after the comments on MLs
. Retain Efuse offsets check to identify a particular OPP.
. Introduce a common header file accessible both by arch/arm/mach-omap2/
and drivers/.
. Retain the class driver in mach-omap2/ and move IP driver to drivers/power/
avs since class driver needs voltage layer support.

History:
v2: rework after the comments on MLs
. Keep the OMAP Kconfig options in the arch dir (Rafael),
. Move the shared header file from plat-omap to
include/linux/power/ (Tony)

v1: initial revision

J Keerthy (1):
ARM: OMAP2+: Voltage: Move the omap_volt_data structure to plat

Jean Pihet (9):
ARM: OMAP2+: SmartReflex: move the smartreflex header to include/linux/power
ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr *
ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of
voltage domains.
ARM: OMAP3: hwmod: rename the smartreflex entries
ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
ARM: OMAP2+: SmartReflex: Use per-OPP data structure
ARM: OMAP2+: SmartReflex: Create per-opp debugfs node for errminlimit
ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options
ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/
arch/arm/mach-omap2/Makefile | 5 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 3 +-
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/smartreflex-class3.c | 29 ++--
arch/arm/mach-omap2/sr_device.c | 39 ++++-
arch/arm/mach-omap2/voltage.h | 21 +---
arch/arm/plat-omap/Kconfig | 31 ++--
arch/arm/plat-omap/include/plat/voltage.h | 21 +++-
drivers/power/Kconfig | 2 +
drivers/power/Makefile | 1 +
drivers/power/avs/Kconfig | 12 ++
drivers/power/avs/Makefile | 1 +
.../mach-omap2 => drivers/power/avs}/smartreflex.c | 161 ++++++++------------
.../linux/power}/smartreflex.h | 74 ++++++++--
15 files changed, 235 insertions(+), 179 deletions(-)
create mode 100644 drivers/power/avs/Kconfig
create mode 100644 drivers/power/avs/Makefile
rename {arch/arm/mach-omap2 => drivers/power/avs}/smartreflex.c (90%)
rename {arch/arm/mach-omap2 => include/linux/power}/smartreflex.h (79%)

--
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

Apr 26, 2012, 11:05 AM

Post #2 of 22 (235 views)
Permalink

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

broonie at opensource

Apr 26, 2012, 12:11 PM

Post #3 of 22 (234 views)
Permalink

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

On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy <j-keerthy [at] ti>
>
> AVS(Adaptive Voltage Scaling) is a power management technique which
> controls the operating voltage of a device in order to optimize (i.e. reduce)
> its power consumption. The voltage is adapted depending on static factors
> (chip manufacturing process) and dynamic factors (temperature
> depending performance).
> The TI AVS solution is named Smartreflex.

What's the relationship between this and existing things like devfreq
and cpufreq? It'd be better if the changelogs made this clear and
provided an overview of how all these different subsystems are intended
to fit together.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

Apr 26, 2012, 10:39 PM

Post #4 of 22 (234 views)
Permalink

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

Hello Mark,

On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown
<broonie [at] opensource> wrote:
> On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
>> From: J Keerthy <j-keerthy [at] ti>
>>
>> AVS(Adaptive Voltage Scaling) is a power management technique which
>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>> its power consumption. The voltage is adapted depending on static factors
>> (chip manufacturing process) and dynamic factors (temperature
>> depending performance).
>> The TI AVS solution is named Smartreflex.
>
> What's the relationship between this and existing things like devfreq
> and cpufreq? �It'd be better if the changelogs made this clear and
> provided an overview of how all these different subsystems are intended
> to fit together.

Devfreq and cpufreq are related to dynamic frequency/voltage switching between
pre defined Operating Performance Points or the OPPs. Every OPP being
a voltage/frequency pair. Smartreflex is a different
power management technique.

SmartReflex is a technology that uses adaptive
power supply to achieve the goal of reducing active power consumption.
With SmartReflex, the power supply voltage can be adapted to the silicon
performance either statically (for example, adapted to the manufacturing process
of a given device), or dynamically (for example, adapted to the temperature
induced current performance of the device).

So for every OPP(voltage/frequency pair) depending on the silicon process and
temperature the Smartreflex tries to get the voltage to an optimal
value at which
the corresponding frequency can be sustained.

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

broonie at opensource

Apr 27, 2012, 10:56 AM

Post #5 of 22 (232 views)
Permalink

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

On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:

> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> pre defined Operating Performance Points or the OPPs. Every OPP being
> a voltage/frequency pair. Smartreflex is a different
> power management technique.

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?

Attachments:

signature.asc (0.82 KB)

khilman at ti

Apr 27, 2012, 2:01 PM

Post #6 of 22 (234 views)
Permalink

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

Hi Mark,

Mark Brown <broonie [at] opensource> writes:

> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>
>> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>> pre defined Operating Performance Points or the OPPs. Every OPP being
>> a voltage/frequency pair. Smartreflex is a different
>> power management technique.
>
> 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.

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

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.

The only thing the higher-level layers might potentially need to do to
enable/disable AVS around transitions (e.g. when changing OPP, AVS is
disabled before changing OPP and only re-enabled when the new nominal
voltage has been acheived.)

On OMAP, we handle this inside the OMAP-specific voltage layer which is
called by the regulator framework, so even the regulators do not need
any knowledge of AVS.

Kevin

[1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a
detailed diagram:
http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

Apr 29, 2012, 9:25 PM

Post #7 of 22 (223 views)
Permalink

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

On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman [at] ti> wrote:
> Hi Mark,
>
> Mark Brown <broonie [at] opensource> writes:
>
>> On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>>
>>> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>>> pre defined Operating Performance Points or the OPPs. Every OPP being
>>> a voltage/frequency pair. Smartreflex is a different
>>> power management technique.
>>
>> 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.
>
> 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].)
>
> 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.
>
> The only thing the higher-level layers might potentially need to do to
> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
> disabled before changing OPP and only re-enabled when the new nominal
> voltage has been acheived.)
>
> On OMAP, we handle this inside the OMAP-specific voltage layer which is
> called by the regulator framework, so even the regulators do not need
> any knowledge of AVS.
>
> Kevin
>
> [1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a
> � �detailed diagram:
> � �http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip

Thanks for the detailed answer Kevin.

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

broonie at opensource

Apr 30, 2012, 2:54 AM

Post #8 of 22 (223 views)
Permalink

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

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

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.

Attachments:

signature.asc (0.82 KB)

khilman at ti

Apr 30, 2012, 2:51 PM

Post #9 of 22 (223 views)
Permalink

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

Mark Brown <broonie [at] opensource> writes:

> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>> Mark Brown <broonie [at] opensource> 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-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

May 1, 2012, 10:04 PM

Post #10 of 22 (218 views)
Permalink

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

On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman [at] ti> wrote:
> Mark Brown <broonie [at] opensource> writes:
>
>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>>> Mark Brown <broonie [at] opensource> 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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

May 3, 2012, 10:05 PM

Post #11 of 22 (217 views)
Permalink

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

On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy [at] ti> wrote:
> On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman [at] ti> wrote:
>> Mark Brown <broonie [at] opensource> writes:
>>
>>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>>>> Mark Brown <broonie [at] opensource> 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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

anilkumar at ti

May 4, 2012, 1:21 AM

Post #12 of 22 (217 views)
Permalink

RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <broonie [at] opensource> writes:
>
> > On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> >
> >> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> >> pre defined Operating Performance Points or the OPPs. Every OPP being
> >> a voltage/frequency pair. Smartreflex is a different
> >> power management technique.
> >
> > 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.
>
> 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].)
>
> 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.
>
> The only thing the higher-level layers might potentially need to do to
> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
> disabled before changing OPP and only re-enabled when the new nominal
> voltage has been acheived.)
>
> On OMAP, we handle this inside the OMAP-specific voltage layer which is
> called by the regulator framework, so even the regulators do not need
> any knowledge of AVS.

Kevin,

I want to point out some cases of SR implementation where this may not
be true.

Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.

Under this, SR module issues an interrupt to ARM when there is a need to
change the voltage based on temperature changes, ageing etc.

Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
The voltage change is a micro adjustment as in other SR classes.

The SR class 2B implementation on these devices does not exist in mainline.
I can point to some public repositories if you are interested in taking a look at
the current code.

Implementation of this SR method is must on at least the DM8168 device and
I know some customers who are using it on their production systems.

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

khilman at ti

May 7, 2012, 4:48 PM

Post #13 of 22 (213 views)
Permalink

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

"AnilKumar, Chimata" <anilkumar [at] ti> writes:

> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>> Hi Mark,
>>
>> Mark Brown <broonie [at] opensource> writes:
>>
>> > On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>> >
>> >> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>> >> pre defined Operating Performance Points or the OPPs. Every OPP being
>> >> a voltage/frequency pair. Smartreflex is a different
>> >> power management technique.
>> >
>> > 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.
>>
>> 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].)
>>
>> 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.
>>
>> The only thing the higher-level layers might potentially need to do to
>> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
>> disabled before changing OPP and only re-enabled when the new nominal
>> voltage has been acheived.)
>>
>> On OMAP, we handle this inside the OMAP-specific voltage layer which is
>> called by the regulator framework, so even the regulators do not need
>> any knowledge of AVS.
>
> Kevin,
>
> I want to point out some cases of SR implementation where this may not
> be true.
>
> Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.
>
> Under this, SR module issues an interrupt to ARM when there is a need to
> change the voltage based on temperature changes, ageing etc.
>
> Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
> The voltage change is a micro adjustment as in other SR classes.

That can easily be handled writing a plugin specific to class 2B. This
driver was designed so plugins for other classes can be supported.

Sure, we might need some enhancements for other classes (we already know
that we will for class 1 support.) However, the purpose of this series
is to do the cleanups necessary for the driver to move to drivers/*.

Support for additional classes can be added after the driver is moved
if/when folks are motivated to post that support upstream.

> The SR class 2B implementation on these devices does not exist in mainline.
> I can point to some public repositories if you are interested in taking a look at
> the current code.

No thanks. We can discuss it when you post support for it to mainline.

Kevin

> Implementation of this SR method is must on at least the DM8168 device and
> I know some customers who are using it on their production systems.
>
> Regards
> AnilKumar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khilman at ti

May 7, 2012, 4:51 PM

Post #14 of 22 (217 views)
Permalink

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

Rafael,

Keerthy <j-keerthy [at] ti> writes:

> From: J Keerthy <j-keerthy [at] ti>
>
> AVS(Adaptive Voltage Scaling) is a power management technique which
> controls the operating voltage of a device in order to optimize (i.e. reduce)
> its power consumption. The voltage is adapted depending on static factors
> (chip manufacturing process) and dynamic factors (temperature
> depending performance).
> The TI AVS solution is named Smartreflex.
>
> To that end, create the AVS driver in drivers/power/avs and
> move the OMAP SmartReflex code to the new directory. The
> class driver is still retained in the mach-omap2 directory.

How should we handle this for upstream?

It does a bunch of cleanup under arch/arm then does the move to
drivers/power the end. To avoid conflicts with other OMAP core changes,
I would suggest we take this through the OMAP tree.

With your ack, I'd be glad to take it.

Thanks,

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

May 7, 2012, 8:48 PM

Post #15 of 22 (214 views)
Permalink

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

On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <khilman [at] ti> wrote:
> "AnilKumar, Chimata" <anilkumar [at] ti> writes:
>
>> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>>> Hi Mark,
>>>
>>> Mark Brown <broonie [at] opensource> writes:
>>>
>>> > On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
>>> >
>>> >> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
>>> >> pre defined Operating Performance Points or the OPPs. Every OPP being
>>> >> a voltage/frequency pair. Smartreflex is a different
>>> >> power management technique.
>>> >
>>> > 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.
>>>
>>> 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].)
>>>
>>> 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.
>>>
>>> The only thing the higher-level layers might potentially need to do to
>>> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
>>> disabled before changing OPP and only re-enabled when the new nominal
>>> voltage has been acheived.)
>>>
>>> On OMAP, we handle this inside the OMAP-specific voltage layer which is
>>> called by the regulator framework, so even the regulators do not need
>>> any knowledge of AVS.
>>
>> Kevin,
>>
>> I want to point out some cases of SR implementation where this may not
>> be true.
>>
>> Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.
>>
>> Under this, SR module issues an interrupt to ARM when there is a need to
>> change the voltage based on temperature changes, ageing etc.
>>
>> Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
>> The voltage change is a micro adjustment as in other SR classes.
>
> That can easily be handled writing a plugin specific to class 2B. �This
> driver was designed so plugins for other classes can be supported.
>
> Sure, we might need some enhancements for other classes (we already know
> that we will for class 1 support.) �However, the purpose of this series
> is to do the cleanups necessary for the driver to move to drivers/*.

AnilKumar,

The intent of the series as explained by Kevin if to do the necessary clean up
for the driver to move from mach-omap to drivers/*. We will for sure need
more enhancements for other classes support.

>
> Support for additional classes can be added after the driver is moved
> if/when folks are motivated to post that support upstream.
>
>> The SR class 2B implementation on these devices does not exist in mainline.
>> I can point to some public repositories if you are interested in taking a look at
>> the current code.
>
> No thanks. �We can discuss it when you post support for it to mainline.
>
> Kevin
>
>> Implementation of this SR method is must on at least the DM8168 device and
>> I know some customers who are using it on their production systems.
>>
>> Regards
>> AnilKumar
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo [at] vger
>> More majordomo info at �http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at �http://www.tux.org/lkml/

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

anilkumar at ti

May 8, 2012, 3:17 AM

Post #16 of 22 (214 views)
Permalink

RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <anilkumar [at] ti> writes:
>
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >>
> >> Mark Brown <broonie [at] opensource> writes:
> >>
> >> > On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> >> >
> >> >> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> >> >> pre defined Operating Performance Points or the OPPs. Every OPP being
> >> >> a voltage/frequency pair. Smartreflex is a different
> >> >> power management technique.
> >> >
> >> > 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.
> >>
> >> 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].)
> >>
> >> 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.
> >>
> >> The only thing the higher-level layers might potentially need to do to
> >> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
> >> disabled before changing OPP and only re-enabled when the new nominal
> >> voltage has been acheived.)
> >>
> >> On OMAP, we handle this inside the OMAP-specific voltage layer which is
> >> called by the regulator framework, so even the regulators do not need
> >> any knowledge of AVS.
> >
> > Kevin,
> >
> > I want to point out some cases of SR implementation where this may not
> > be true.
> >
> > Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.
> >
> > Under this, SR module issues an interrupt to ARM when there is a need to
> > change the voltage based on temperature changes, ageing etc.
> >
> > Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
> > The voltage change is a micro adjustment as in other SR classes.
>
> That can easily be handled writing a plugin specific to class 2B. This
> driver was designed so plugins for other classes can be supported.
>
> Sure, we might need some enhancements for other classes (we already know
> that we will for class 1 support.) However, the purpose of this series
> is to do the cleanups necessary for the driver to move to drivers/*.
>

It's perfectly fine with me. My intention was just to highlight that
class 2B SR will have to interact with regulator layer for voltage
changes, so I guess it is little different from other SR classes.

Thanks,
AnilKumar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

r-woodruff2 at ti

May 8, 2012, 1:38 PM

Post #17 of 22 (215 views)
Permalink

RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

> > >> The only thing the higher-level layers might potentially need to do
> > >> is to enable/disable AVS around transitions (e.g. when changing OPP, > > >> AVS is disabled before changing OPP and only re-enabled when the new > >> >> nominal voltage has been acheived.)

Getting clean baseline in place is huge step but actual production interfaces will need to comprehend some OPP to AVS dependencies beyond on/off.

AVS as used in many OMAP designs (mostly > OMAP4430) do have some per OPP dependent details:

- Multiple PMICs are in use. In some current designs the AVS step size is different per voltage range. At OPP change time you have to reconfigure several AVS parameters before enable.

- ABB-ldo sequencing and parameters in tightly coupled with OPP and AVS enables.

- Good power savings can be had in future 1.5/3.5 by adjusting nominal to calibrated-plus-margin voltage.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

May 14, 2012, 10:46 PM

Post #18 of 22 (210 views)
Permalink

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

On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman [at] ti> wrote:
> Rafael,
>
> Keerthy <j-keerthy [at] ti> writes:
>
>> From: J Keerthy <j-keerthy [at] ti>
>>
>> AVS(Adaptive Voltage Scaling) is a power management technique which
>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>> its power consumption. The voltage is adapted depending on static factors
>> (chip manufacturing process) and dynamic factors (temperature
>> depending performance).
>> The TI AVS solution is named Smartreflex.
>>
>> To that end, create the AVS driver in drivers/power/avs and
>> move the OMAP SmartReflex code to the new directory. The
>> class driver is still retained in the mach-omap2 directory.
>
> How should we handle this for upstream?
>
> It does a bunch of cleanup under arch/arm then does the move to
> drivers/power the end. �To avoid conflicts with other OMAP core changes,
> I would suggest we take this through the OMAP tree.
>
> With your ack, I'd be glad to take it.

Hello Rafael,

A gentle ping on this series.

>
> Thanks,
>
> Kevin
>

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

j-keerthy at ti

May 22, 2012, 9:51 PM

Post #19 of 22 (191 views)
Permalink

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

On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy [at] ti> wrote:
> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman [at] ti> wrote:
>> Rafael,
>>
>> Keerthy <j-keerthy [at] ti> writes:
>>
>>> From: J Keerthy <j-keerthy [at] ti>
>>>
>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>> its power consumption. The voltage is adapted depending on static factors
>>> (chip manufacturing process) and dynamic factors (temperature
>>> depending performance).
>>> The TI AVS solution is named Smartreflex.
>>>
>>> To that end, create the AVS driver in drivers/power/avs and
>>> move the OMAP SmartReflex code to the new directory. The
>>> class driver is still retained in the mach-omap2 directory.
>>
>> How should we handle this for upstream?
>>
>> It does a bunch of cleanup under arch/arm then does the move to
>> drivers/power the end. �To avoid conflicts with other OMAP core changes,
>> I would suggest we take this through the OMAP tree.
>>
>> With your ack, I'd be glad to take it.
>
> Hello Rafael,
>
> A gentle ping on this series.

Hi Greg,

This series has Kevin's comments incorporated.

Kevin,

Can i have your Ack for this series?

>
>>
>> Thanks,
>>
>> Kevin
>>
>
>
>
> --
> 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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khilman at ti

May 24, 2012, 10:24 AM

Post #20 of 22 (189 views)
Permalink

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

"J, KEERTHY" <j-keerthy [at] ti> writes:

> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy [at] ti> wrote:
>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman [at] ti> wrote:
>>> Rafael,
>>>
>>> Keerthy <j-keerthy [at] ti> writes:
>>>
>>>> From: J Keerthy <j-keerthy [at] ti>
>>>>
>>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>>> its power consumption. The voltage is adapted depending on static factors
>>>> (chip manufacturing process) and dynamic factors (temperature
>>>> depending performance).
>>>> The TI AVS solution is named Smartreflex.
>>>>
>>>> To that end, create the AVS driver in drivers/power/avs and
>>>> move the OMAP SmartReflex code to the new directory. The
>>>> class driver is still retained in the mach-omap2 directory.
>>>
>>> How should we handle this for upstream?
>>>
>>> It does a bunch of cleanup under arch/arm then does the move to
>>> drivers/power the end. To avoid conflicts with other OMAP core changes,
>>> I would suggest we take this through the OMAP tree.
>>>
>>> With your ack, I'd be glad to take it.
>>
>> Hello Rafael,
>>
>> A gentle ping on this series.
>
> Hi Greg,
>
> This series has Kevin's comments incorporated.
>
> Kevin,
>
> Can i have your Ack for this series?
>

Well, as mentioned above, I'm waiting for Rafael's ack, then I will
merge it.

Because of all the arch/arm/mach-omap2/* changes, I would like to merge
this via the OMAP tree to avoid conflicts with other stuff we have
changing in arch/arm/mach-omap2/*

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

khilman at ti

May 31, 2012, 3:40 PM

Post #21 of 22 (180 views)
Permalink

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

Kevin Hilman <khilman [at] ti> writes:

> "J, KEERTHY" <j-keerthy [at] ti> writes:
>
>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy [at] ti> wrote:
>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman [at] ti> wrote:
>>>> Rafael,
>>>>
>>>> Keerthy <j-keerthy [at] ti> writes:
>>>>
>>>>> From: J Keerthy <j-keerthy [at] ti>
>>>>>
>>>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>>>> its power consumption. The voltage is adapted depending on static factors
>>>>> (chip manufacturing process) and dynamic factors (temperature
>>>>> depending performance).
>>>>> The TI AVS solution is named Smartreflex.
>>>>>
>>>>> To that end, create the AVS driver in drivers/power/avs and
>>>>> move the OMAP SmartReflex code to the new directory. The
>>>>> class driver is still retained in the mach-omap2 directory.
>>>>
>>>> How should we handle this for upstream?
>>>>
>>>> It does a bunch of cleanup under arch/arm then does the move to
>>>> drivers/power the end. To avoid conflicts with other OMAP core changes,
>>>> I would suggest we take this through the OMAP tree.
>>>>
>>>> With your ack, I'd be glad to take it.
>>>
>>> Hello Rafael,
>>>
>>> A gentle ping on this series.
>>
>> Hi Greg,
>>
>> This series has Kevin's comments incorporated.
>>
>> Kevin,
>>
>> Can i have your Ack for this series?
>>
>
> Well, as mentioned above, I'm waiting for Rafael's ack, then I will
> merge it.
>
> Because of all the arch/arm/mach-omap2/* changes, I would like to merge
> this via the OMAP tree to avoid conflicts with other stuff we have
> changing in arch/arm/mach-omap2/*

OK, I had an off-line discussion with Rafael and he's OK that I take
these. I will add an ack from Rafael and queue this series up for v3.6.

Thanks,

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

j-keerthy at ti

May 31, 2012, 8:45 PM

Post #22 of 22 (176 views)
Permalink

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

On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman <khilman [at] ti> wrote:
> Kevin Hilman <khilman [at] ti> writes:
>
>> "J, KEERTHY" <j-keerthy [at] ti> writes:
>>
>>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy [at] ti> wrote:
>>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman [at] ti> wrote:
>>>>> Rafael,
>>>>>
>>>>> Keerthy <j-keerthy [at] ti> writes:
>>>>>
>>>>>> From: J Keerthy <j-keerthy [at] ti>
>>>>>>
>>>>>> AVS(Adaptive Voltage Scaling) is a power management technique which
>>>>>> controls the operating voltage of a device in order to optimize (i.e. reduce)
>>>>>> its power consumption. The voltage is adapted depending on static factors
>>>>>> (chip manufacturing process) and dynamic factors (temperature
>>>>>> depending performance).
>>>>>> The TI AVS solution is named Smartreflex.
>>>>>>
>>>>>> To that end, create the AVS driver in drivers/power/avs and
>>>>>> move the OMAP SmartReflex code to the new directory. The
>>>>>> class driver is still retained in the mach-omap2 directory.
>>>>>
>>>>> How should we handle this for upstream?
>>>>>
>>>>> It does a bunch of cleanup under arch/arm then does the move to
>>>>> drivers/power the end. �To avoid conflicts with other OMAP core changes,
>>>>> I would suggest we take this through the OMAP tree.
>>>>>
>>>>> With your ack, I'd be glad to take it.
>>>>
>>>> Hello Rafael,
>>>>
>>>> A gentle ping on this series.
>>>
>>> Hi Greg,
>>>
>>> This series has Kevin's comments incorporated.
>>>
>>> Kevin,
>>>
>>> Can i have your Ack for this series?
>>>
>>
>> Well, as mentioned above, I'm waiting for Rafael's ack, then I will
>> merge it.
>>
>> Because of all the arch/arm/mach-omap2/* changes, I would like to merge
>> this via the OMAP tree to avoid conflicts with other stuff we have
>> changing in arch/arm/mach-omap2/*
>
> OK, I had an off-line discussion with Rafael and he's OK that I take
> these. �I will add an ack from Rafael and queue this series up for v3.6.

Thanks Kevin.

>
> Thanks,
>
> Kevin

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads