Enclosed please find the link to the Meeting Minutes & Weekly Status report
for the Power Management working group for the week ending 2011-08-26.
== Meeting Minutes == https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-08-31
== Weekly Status Report == https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-01
== Summary ==
* Made hotplug power measurements on st-e u8500 platform * mp3 playback test showed between 7 to 8% power improvement * cpuhotplug - For Linux idle case, no visible improvement as power is already very low * Finished GPIO support in power debug. * linaro-pm-qa integration with LAVA went well, we should start seeing a daily test of power management suite * Published git tree containing common Samsung save and restore code * Preparing thermal framework for upstreaming and preparing slides for Plumbers conference * Started to work on integration of thermal with OMAP4460 power management * Re-writing cpuidle driver * Started design work on struct clk, created some notes and design points for discussion at LPC * Rebased PMWG kernel git tree to 3.1-rc4
Best regards, Mounir
On Thu, Sep 01, 2011 at 02:22:03PM -0500, Mounir Bsaibes wrote:
- Made hotplug power measurements on st-e u8500 platform
- mp3 playback test showed between 7 to 8% power improvement
- cpuhotplug - For Linux idle case, no visible improvement as power is
already very low
This is using hotplug versus plain cpuidle -- and if so, does this mean that the proper fix is extending cpuidle to go to the lowest power state?
- Re-writing cpuidle driver
For which platforms?
On Fri, Sep 2, 2011 at 6:07 PM, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Sep 01, 2011 at 02:22:03PM -0500, Mounir Bsaibes wrote:
* Made hotplug power measurements on st-e u8500 platform * mp3 playback test showed between 7 to 8% power improvement * cpuhotplug - For Linux idle case, no visible improvement as power is already very low
This is using hotplug versus plain cpuidle -- and if so, does this mean that the proper fix is extending cpuidle to go to the lowest power state?
It isn't extending cpuidle but more like implementing the cpuidle platform-specific driver correctly.
What I find more interesting is that a low-power mp3 usecase (display off, play mp3 at half volume, etc.) still saves 7-8% with hotplug. It'd be worth looking at the scheduler traces to see if the second core is coming into play in the mp3 usecase. Vincent?
* Re-writing cpuidle driver
For which platforms?
For i.MX5. Rob what is the status of posting this to the list?
On 6 September 2011 17:38, Amit Kucheria amit.kucheria@linaro.org wrote:
On Fri, Sep 2, 2011 at 6:07 PM, Christian Robottom Reis kiko@linaro.org wrote:
On Thu, Sep 01, 2011 at 02:22:03PM -0500, Mounir Bsaibes wrote:
* Made hotplug power measurements on st-e u8500 platform * mp3 playback test showed between 7 to 8% power improvement * cpuhotplug - For Linux idle case, no visible improvement as power is already very low
This is using hotplug versus plain cpuidle -- and if so, does this mean that the proper fix is extending cpuidle to go to the lowest power state?
It isn't extending cpuidle but more like implementing the cpuidle platform-specific driver correctly.
What I find more interesting is that a low-power mp3 usecase (display off, play mp3 at half volume, etc.) still saves 7-8% with hotplug. It'd be worth looking at the scheduler traces to see if the second core is coming into play in the mp3 usecase. Vincent?
MP3 uses 2 cpus when they are both onlines. Using 1 cpu provides the best powersaving results mainly because we don't need and use the full power of the dual CA-9. Now, I currently trying to reach the same results with the right scheduler and topology configuration instead of unplugging cpu1. It's on going but I need to play with optimized old kernel and latest non optimized one.
* Re-writing cpuidle driver
For which platforms?
For i.MX5. Rob what is the status of posting this to the list?
-
Amit Kucheria -
Christian Robottom Reis -
Mounir Bsaibes -
Vincent Guittot