Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Kevin Hilman khil...@ti.com writes: J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote: AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
The only thing the higher-level layers might potentially need to do is to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) Getting clean baseline in place is huge step but actual production interfaces will need to comprehend some OPP to AVS dependencies beyond on/off. AVS as used in many OMAP designs (mostly OMAP4430) do have some per OPP dependent details: - Multiple PMICs are in use. In some current designs the AVS step size is different per voltage range. At OPP change time you have to reconfigure several AVS parameters before enable. - ABB-ldo sequencing and parameters in tightly coupled with OPP and AVS enables. - Good power savings can be had in future 1.5/3.5 by adjusting nominal to calibrated-plus-margin voltage. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman khil...@ti.com wrote: AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman khil...@ti.com wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman khil...@ti.com wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@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. signature.asc Description: Digital signature
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman khil...@ti.com wrote: Hi Mark, Mark Brown broo...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
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? signature.asc Description: Digital signature
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Hi Mark, Mark Brown broo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote: From: J Keerthy j-keer...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Hello Mark, On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote: From: J Keerthy j-keer...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
