* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 18:05 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 18:05 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel, linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 18:05 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 18:05 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel, linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 18:05 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 18:05 UTC (permalink / raw)
To: linux-arm-kernel
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-31 22:40 ` Kevin Hilman
@ 2012-06-01 3:45 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-06-01 3:45 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> "J, KEERTHY" <j-keerthy@ti.com> writes:
>>
>>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>>> Rafael,
>>>>>
>>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>>
>>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>>
>>>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-06-01 3:45 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-06-01 3:45 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman <khilman@ti.com> wrote:
> Kevin Hilman <khilman@ti.com> writes:
>
>> "J, KEERTHY" <j-keerthy@ti.com> writes:
>>
>>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>>> Rafael,
>>>>>
>>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>>
>>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>>
>>>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-24 17:24 ` Kevin Hilman
(?)
@ 2012-05-31 22:40 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-31 22:40 UTC (permalink / raw)
To: J, KEERTHY
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
Kevin Hilman <khilman@ti.com> writes:
> "J, KEERTHY" <j-keerthy@ti.com> writes:
>
>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>> Rafael,
>>>>
>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>
>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>
>>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-31 22:40 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-31 22:40 UTC (permalink / raw)
To: J, KEERTHY
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
Kevin Hilman <khilman@ti.com> writes:
> "J, KEERTHY" <j-keerthy@ti.com> writes:
>
>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>> Rafael,
>>>>
>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>
>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>
>>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-31 22:40 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-31 22:40 UTC (permalink / raw)
To: linux-arm-kernel
Kevin Hilman <khilman@ti.com> writes:
> "J, KEERTHY" <j-keerthy@ti.com> writes:
>
>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>>> Rafael,
>>>>
>>>> Keerthy <j-keerthy@ti.com> writes:
>>>>
>>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>>
>>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-23 4:51 ` J, KEERTHY
(?)
@ 2012-05-24 17:24 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-24 17:24 UTC (permalink / raw)
To: J, KEERTHY
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
"J, KEERTHY" <j-keerthy@ti.com> writes:
> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> Rafael,
>>>
>>> Keerthy <j-keerthy@ti.com> writes:
>>>
>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>
>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-24 17:24 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-24 17:24 UTC (permalink / raw)
To: J, KEERTHY
Cc: Rafael J. Wysocki, greg, linux-omap, linux-arm-kernel,
linux-kernel, linux-pm, j-pihet
"J, KEERTHY" <j-keerthy@ti.com> writes:
> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> Rafael,
>>>
>>> Keerthy <j-keerthy@ti.com> writes:
>>>
>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>
>>>> 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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-24 17:24 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-24 17:24 UTC (permalink / raw)
To: linux-arm-kernel
"J, KEERTHY" <j-keerthy@ti.com> writes:
> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> Rafael,
>>>
>>> Keerthy <j-keerthy@ti.com> writes:
>>>
>>>> From: J Keerthy <j-keerthy@ti.com>
>>>>
>>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-09 18:29 ` [linux-pm] " Kevin Hilman
@ 2012-05-23 13:27 ` Menon, Nishanth
0 siblings, 0 replies; 65+ messages in thread
From: Menon, Nishanth @ 2012-05-23 13:27 UTC (permalink / raw)
To: Kevin Hilman
Cc: J, KEERTHY, Mark Brown, linux-kernel, AnilKumar, Chimata,
linux-pm, linux-omap, Pihet-XID, Jean, linux-arm-kernel
On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <khilman@ti.com> wrote:
> "Woodruff, Richard" <r-woodruff2@ti.com> writes:
>
>>> From: Hilman, Kevin
>>> Sent: Tuesday, May 08, 2012 5:17 PM
>>
>>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>>> have not seen support submitted for all of these features.
>>
>> 1.5/3.5 is a feature.
>
> And I'm still waiting for it to be submitted upstream.
>
>> ABB is requirement for a production useable driver. Higher speed rated
>> OMAP4 and all OMAP5 added these to be useable.
>
> ditto
>
>> Yes this is effort. Point of mentioning is to raise awareness of need.
>
> I'm well aware of the need.
>
>> Yet to be added feature has different meaning than functional gap.
>
> And both need to be submitted upstream.
SR 1.5: http://marc.info/?l=linux-omap&m=129933897910785&w=2
ABB: http://marc.info/?l=linux-omap&m=130939399209099&w=2
I am not sure what you mean "need to be submitted upstream"?
Just tired of seeing things perpetually change without considering
even how to handle features that are mandatory for SoC even with code
posted upstream to show exactly what it takes.. I think you do mean
merged upstream in this context.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-15 5:46 ` J, KEERTHY
@ 2012-05-23 4:51 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-23 4:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Kevin Hilman, greg
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-pm, j-pihet
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Rafael,
>>
>> Keerthy <j-keerthy@ti.com> writes:
>>
>>> From: J Keerthy <j-keerthy@ti.com>
>>>
>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-23 4:51 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-23 4:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Rafael,
>>
>> Keerthy <j-keerthy@ti.com> writes:
>>
>>> From: J Keerthy <j-keerthy@ti.com>
>>>
>>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-07 23:51 ` Kevin Hilman
(?)
@ 2012-05-15 5:46 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-15 5:46 UTC (permalink / raw)
To: Rafael J. Wysocki, Kevin Hilman
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-pm, j-pihet
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
> Rafael,
>
> Keerthy <j-keerthy@ti.com> writes:
>
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-15 5:46 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-15 5:46 UTC (permalink / raw)
To: Rafael J. Wysocki, Kevin Hilman
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-pm, j-pihet
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
> Rafael,
>
> Keerthy <j-keerthy@ti.com> writes:
>
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> 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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-15 5:46 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-15 5:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman <khilman@ti.com> wrote:
> Rafael,
>
> Keerthy <j-keerthy@ti.com> writes:
>
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-08 22:16 ` [linux-pm] " Kevin Hilman
@ 2012-05-09 0:39 ` Woodruff, Richard
2012-05-09 18:29 ` [linux-pm] " Kevin Hilman
0 siblings, 1 reply; 65+ messages in thread
From: Woodruff, Richard @ 2012-05-09 0:39 UTC (permalink / raw)
To: Hilman, Kevin
Cc: J, KEERTHY, Mark Brown, linux-kernel, AnilKumar, Chimata,
linux-pm, linux-omap, Pihet-XID, Jean, linux-arm-kernel
> From: Hilman, Kevin
> Sent: Tuesday, May 08, 2012 5:17 PM
> A basic OMAP AVS driver has been in mainline for a long time, yet we
> have not seen support submitted for all of these features.
1.5/3.5 is a feature.
ABB is requirement for a production useable driver. Higher speed rated OMAP4 and all OMAP5 added these to be useable. Yes this is effort. Point of mentioning is to raise awareness of need.
Yet to be added feature has different meaning than functional gap.
Regards,
Richard W.
^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-08 10:17 ` AnilKumar, Chimata
(?)
@ 2012-05-08 20:38 ` Woodruff, Richard
-1 siblings, 0 replies; 65+ messages in thread
From: Woodruff, Richard @ 2012-05-08 20:38 UTC (permalink / raw)
To: AnilKumar, Chimata, Hilman, Kevin
Cc: Mark Brown, J, KEERTHY, linux-omap, linux-arm-kernel, rjw,
linux-kernel, linux-pm, Pihet-XID, Jean
> > >> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 20:38 ` Woodruff, Richard
0 siblings, 0 replies; 65+ messages in thread
From: Woodruff, Richard @ 2012-05-08 20:38 UTC (permalink / raw)
To: AnilKumar, Chimata, Hilman, Kevin
Cc: J, KEERTHY, Mark Brown, linux-kernel, linux-pm, linux-omap,
Pihet-XID, Jean, linux-arm-kernel
> > >> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 20:38 ` Woodruff, Richard
0 siblings, 0 replies; 65+ messages in thread
From: Woodruff, Richard @ 2012-05-08 20:38 UTC (permalink / raw)
To: linux-arm-kernel
> > >> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-07 23:48 ` Kevin Hilman
(?)
@ 2012-05-08 10:17 ` AnilKumar, Chimata
-1 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-08 10:17 UTC (permalink / raw)
To: Hilman, Kevin
Cc: Mark Brown, J, KEERTHY, linux-omap, linux-arm-kernel, rjw,
linux-kernel, linux-pm, Pihet-XID, Jean
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >>
> >> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 10:17 ` AnilKumar, Chimata
0 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-08 10:17 UTC (permalink / raw)
To: Hilman, Kevin
Cc: Mark Brown, J, KEERTHY, linux-omap, linux-arm-kernel, rjw,
linux-kernel, linux-pm, Pihet-XID, Jean
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >>
> >> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 10:17 ` AnilKumar, Chimata
0 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-08 10:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >>
> >> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-07 23:48 ` Kevin Hilman
(?)
@ 2012-05-08 3:48 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-08 3:48 UTC (permalink / raw)
To: Kevin Hilman, AnilKumar, Chimata
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, Pihet-XID, Jean
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <khilman@ti.com> wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
>> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>>> Hi Mark,
>>>
>>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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@vger.kernel.org
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 3:48 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-08 3:48 UTC (permalink / raw)
To: Kevin Hilman, AnilKumar, Chimata
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, Pihet-XID, Jean
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <khilman@ti.com> wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
>> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>>> Hi Mark,
>>>
>>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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@vger.kernel.org
>> 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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-08 3:48 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-08 3:48 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <khilman@ti.com> wrote:
> "AnilKumar, Chimata" <anilkumar@ti.com> writes:
>
>> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>>> Hi Mark,
>>>
>>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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.kernel.org
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-26 17:40 ` Keerthy
(?)
@ 2012-05-07 23:51 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:51 UTC (permalink / raw)
To: Keerthy, Rafael J. Wysocki
Cc: linux-omap, linux-arm-kernel, rjw, linux-kernel, linux-pm, j-pihet
Rafael,
Keerthy <j-keerthy@ti.com> writes:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-07 23:51 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:51 UTC (permalink / raw)
To: Keerthy
Cc: linux-omap, linux-arm-kernel, rjw, linux-kernel, linux-pm, j-pihet
Rafael,
Keerthy <j-keerthy@ti.com> writes:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-07 23:51 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:51 UTC (permalink / raw)
To: linux-arm-kernel
Rafael,
Keerthy <j-keerthy@ti.com> writes:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-04 8:21 ` AnilKumar, Chimata
(?)
@ 2012-05-07 23:48 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:48 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: Mark Brown, J, KEERTHY, linux-omap, linux-arm-kernel, rjw,
linux-kernel, linux-pm, Pihet-XID, Jean
"AnilKumar, Chimata" <anilkumar@ti.com> writes:
> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>> Hi Mark,
>>
>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-07 23:48 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:48 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: Mark Brown, J, KEERTHY, linux-omap, linux-arm-kernel, rjw,
linux-kernel, linux-pm, Pihet-XID, Jean
"AnilKumar, Chimata" <anilkumar@ti.com> writes:
> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>> Hi Mark,
>>
>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-07 23:48 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-05-07 23:48 UTC (permalink / raw)
To: linux-arm-kernel
"AnilKumar, Chimata" <anilkumar@ti.com> writes:
> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>> Hi Mark,
>>
>> Mark Brown <broonie@opensource.wolfsonmicro.com> 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.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-27 21:01 ` Kevin Hilman
(?)
@ 2012-05-04 8:21 ` AnilKumar, Chimata
-1 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-04 8:21 UTC (permalink / raw)
To: Hilman, Kevin, Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, Pihet-XID, Jean
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-04 8:21 ` AnilKumar, Chimata
0 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-04 8:21 UTC (permalink / raw)
To: Hilman, Kevin, Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, Pihet-XID, Jean
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-04 8:21 ` AnilKumar, Chimata
0 siblings, 0 replies; 65+ messages in thread
From: AnilKumar, Chimata @ 2012-05-04 8:21 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-05-02 5:04 ` J, KEERTHY
(?)
@ 2012-05-04 5:05 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-04 5:05 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-04 5:05 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-04 5:05 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> 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.
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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-04 5:05 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-04 5:05 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-30 21:51 ` Kevin Hilman
(?)
@ 2012-05-02 5:04 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-02 5:04 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-02 5:04 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-02 5:04 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-05-02 5:04 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-05-02 5:04 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-30 9:54 ` Mark Brown
(?)
@ 2012-04-30 21:51 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-30 21:51 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 21:51 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-30 21:51 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 21:51 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-30 21:51 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-27 21:01 ` Kevin Hilman
(?)
@ 2012-04-30 9:54 ` Mark Brown
-1 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-30 9:54 UTC (permalink / raw)
To: Kevin Hilman
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]
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 :)
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 9:54 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-30 9:54 UTC (permalink / raw)
To: Kevin Hilman
Cc: J, KEERTHY, linux-kernel, linux-pm, linux-omap, j-pihet,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2023 bytes --]
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 :)
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.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 9:54 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-30 9:54 UTC (permalink / raw)
To: linux-arm-kernel
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 :)
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 part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120430/b3bfa9e7/attachment.sig>
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-27 21:01 ` Kevin Hilman
(?)
@ 2012-04-30 4:25 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-04-30 4:25 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman@ti.com> wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 4:25 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-04-30 4:25 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman@ti.com> wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-30 4:25 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-04-30 4:25 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman <khilman@ti.com> wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-27 17:56 ` Mark Brown
(?)
@ 2012-04-27 21:01 ` Kevin Hilman
-1 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-27 21:01 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
Hi Mark,
Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-27 21:01 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-27 21:01 UTC (permalink / raw)
To: Mark Brown
Cc: J, KEERTHY, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet
Hi Mark,
Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-27 21:01 ` Kevin Hilman
0 siblings, 0 replies; 65+ messages in thread
From: Kevin Hilman @ 2012-04-27 21:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark,
Mark Brown <broonie@opensource.wolfsonmicro.com> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-27 5:39 ` J, KEERTHY
(?)
@ 2012-04-27 17:56 ` Mark Brown
-1 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-27 17:56 UTC (permalink / raw)
To: J, KEERTHY
Cc: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm, j-pihet
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
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?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-27 17:56 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-27 17:56 UTC (permalink / raw)
To: J, KEERTHY
Cc: khilman, linux-kernel, linux-pm, linux-omap, j-pihet, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 454 bytes --]
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?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-27 17:56 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-27 17:56 UTC (permalink / raw)
To: linux-arm-kernel
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120427/0bce95d8/attachment.sig>
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-26 19:11 ` Mark Brown
@ 2012-04-27 5:39 ` J, KEERTHY
-1 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-04-27 5:39 UTC (permalink / raw)
To: Mark Brown
Cc: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm, j-pihet
Hello Mark,
On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-27 5:39 ` J, KEERTHY
0 siblings, 0 replies; 65+ messages in thread
From: J, KEERTHY @ 2012-04-27 5:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello Mark,
On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
>> From: J Keerthy <j-keerthy@ti.com>
>>
>> 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
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
2012-04-26 17:40 ` Keerthy
(?)
@ 2012-04-26 19:11 ` Mark Brown
-1 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-26 19:11 UTC (permalink / raw)
To: Keerthy
Cc: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel,
linux-pm, j-pihet
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 19:11 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-26 19:11 UTC (permalink / raw)
To: Keerthy
Cc: khilman, linux-kernel, linux-pm, linux-omap, j-pihet, linux-arm-kernel
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 19:11 ` Mark Brown
0 siblings, 0 replies; 65+ messages in thread
From: Mark Brown @ 2012-04-26 19:11 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote:
> From: J Keerthy <j-keerthy@ti.com>
>
> 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.
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 17:40 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel, linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 17:40 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-omap, linux-arm-kernel, khilman, rjw, linux-kernel, linux-pm
Cc: j-pihet, j-keerthy
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
@ 2012-04-26 17:40 ` Keerthy
0 siblings, 0 replies; 65+ messages in thread
From: Keerthy @ 2012-04-26 17:40 UTC (permalink / raw)
To: linux-arm-kernel
From: J Keerthy <j-keerthy@ti.com>
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
^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2012-06-01 3:45 UTC | newest]
Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-26 18:05 [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) Keerthy
2012-04-26 18:05 ` Keerthy
2012-04-26 18:05 ` Keerthy
-- strict thread matches above, loose matches on Subject: below --
2012-04-26 17:40 Keerthy
2012-04-26 17:40 ` Keerthy
2012-04-26 17:40 ` Keerthy
2012-04-26 19:11 ` Mark Brown
2012-04-26 19:11 ` Mark Brown
2012-04-26 19:11 ` Mark Brown
2012-04-27 5:39 ` J, KEERTHY
2012-04-27 5:39 ` J, KEERTHY
2012-04-27 17:56 ` Mark Brown
2012-04-27 17:56 ` Mark Brown
2012-04-27 17:56 ` Mark Brown
2012-04-27 21:01 ` Kevin Hilman
2012-04-27 21:01 ` Kevin Hilman
2012-04-27 21:01 ` Kevin Hilman
2012-04-30 4:25 ` J, KEERTHY
2012-04-30 4:25 ` J, KEERTHY
2012-04-30 4:25 ` J, KEERTHY
2012-04-30 9:54 ` Mark Brown
2012-04-30 9:54 ` Mark Brown
2012-04-30 9:54 ` Mark Brown
2012-04-30 21:51 ` Kevin Hilman
2012-04-30 21:51 ` Kevin Hilman
2012-04-30 21:51 ` Kevin Hilman
2012-05-02 5:04 ` J, KEERTHY
2012-05-02 5:04 ` J, KEERTHY
2012-05-02 5:04 ` J, KEERTHY
2012-05-04 5:05 ` J, KEERTHY
2012-05-04 5:05 ` J, KEERTHY
2012-05-04 5:05 ` J, KEERTHY
2012-05-04 8:21 ` AnilKumar, Chimata
2012-05-04 8:21 ` AnilKumar, Chimata
2012-05-04 8:21 ` AnilKumar, Chimata
2012-05-07 23:48 ` Kevin Hilman
2012-05-07 23:48 ` Kevin Hilman
2012-05-07 23:48 ` Kevin Hilman
2012-05-08 3:48 ` J, KEERTHY
2012-05-08 3:48 ` J, KEERTHY
2012-05-08 3:48 ` J, KEERTHY
2012-05-08 10:17 ` AnilKumar, Chimata
2012-05-08 10:17 ` AnilKumar, Chimata
2012-05-08 10:17 ` AnilKumar, Chimata
2012-05-08 20:38 ` Woodruff, Richard
2012-05-08 20:38 ` Woodruff, Richard
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 18:29 ` [linux-pm] " Kevin Hilman
2012-05-23 13:27 ` Menon, Nishanth
2012-05-07 23:51 ` Kevin Hilman
2012-05-07 23:51 ` Kevin Hilman
2012-05-07 23:51 ` Kevin Hilman
2012-05-15 5:46 ` J, KEERTHY
2012-05-15 5:46 ` J, KEERTHY
2012-05-15 5:46 ` J, KEERTHY
2012-05-23 4:51 ` J, KEERTHY
2012-05-23 4:51 ` J, KEERTHY
2012-05-24 17:24 ` Kevin Hilman
2012-05-24 17:24 ` Kevin Hilman
2012-05-24 17:24 ` Kevin Hilman
2012-05-31 22:40 ` Kevin Hilman
2012-05-31 22:40 ` Kevin Hilman
2012-05-31 22:40 ` Kevin Hilman
2012-06-01 3:45 ` J, KEERTHY
2012-06-01 3:45 ` J, KEERTHY
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.