[PM] 25/08/10 - Minutes for the Power Management WG weekly call

Vishwanath Sripathy vishwanath.sripathy at linaro.org
Mon Aug 30 07:00:04 BST 2010


Some updates on Action items:
 * ACTION: Vishwa to verify powertop on 2.6.35
I verified powertop using latest Kevin's pm branch (2.6.35) and it is
working as expected.

Regards
Vishwa

On Wed, Aug 25, 2010 at 3:11 PM, Amit Kucheria <amit.kucheria at linaro.org>wrote:

> The minutes of the weekly call can be found at:
>
> https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-08-25
>
> The minutes and actions are copied below.
>
> Regards,
> Amit
>
> Attendees:
>
> Linaro: Amit Kucheria, Amit Arora, Yong Shen
> ARM: Robin Randhawa, Bobby Batacharia, Srinivas Kalaga
>
>
> == Action Items from this Meeting ==
>  * ACTION: Yong to work with John Rigby and Ubuntu kernel team to make sure
> the Linaro kernel contains powertop kernel patches
>  * ACTION: Vishwa to verify powertop on 2.6.35
>  * ACTION: Vishwa to check with cpuidle/cpufreq experts in TI for verifying
> cpufreq behavior on multi-core OMAP
>  * ACTION: Amit A to get the powertop patch integrated into Linaro/Ubuntu
> packages
>  * ACTION: Yong to test common clk API patches on imx5 and help get it
> booting on babbage 3.0
>
> == Action Items from Previous Meeting ==
>
>  * ACTIVE (Immediate):
>   * ACTION: Amit A to test on pm enabled OMAP3 board: DONE on 2.6.32 on
> zoom3 board
>     * New ACTION: Vishwa to verify on 2.6.35
>   * ACTION: Amit A to document details on power supply class (battery info)
> to PowerTOP internal wiki page: DONE
>   * ACTION: Yong to look into getting powertop kernel patches applied to
> Linaro kernel tree: Not DONE
>     * New ACTION: Yong to work with John Rigby and make sure the Linaro
> kernel contains it
>   * ACTION: Robin to send links to patches sent to linux-pm: DONE
>     * http://www.spinics.net/lists/cpufreq/msg01740.html
>     * It was a pointer to a discussion on having different governors on
> different cores
>   * ACTION: Amit K to spend some time on usecase to reproduce ondemand
> governor problems: POSTPONED
>   * ACTION: Yong to look at common clock FW, find out if debug info being
> exported (usage count, clk rate, dependencies): DONE
>
>  * DORMANT :
>
>  * ACTION: ARM to share  internal  instrumentation flow (BAB: we might also
> align with Linaro on workload discussions)
>     * Might take couple of months
>  * ACTION: Amit K to talk to jeremy about power domain framework: DONE
>     * Jeremy needs help, will revisit in a few weeks
>  * ACTION: Srinivas to provide details of where he believes userspace -
> kernel interaction is required. (low prio)
>  * ACTION: Bobby to check on multi-core boards availability (request open)
>  * ACTION: ARM to discuss giving out internal Eclipse based tool (similar
> to powertop)  (no ETA as of now)
>  * ACTION: Amit Kucheria and Vishwa to get inputs from community on the
> issues related to CPUIDLE governor: POSTPONED until instrumentation work
>
>
> == Minutes ==
>  * Discussion on http://www.spinics.net/lists/cpufreq/msg01740.html
>    * For ARM, both cores run at same frequency (CMP)
>      * Does it make sense for them to run different governors on each core?
>        * The consensus currently is NO
>    * TI uses ondemand governor + policy manager
>      * One core is kept OFF, all processing happens on the other one.
>      * If load on one core goes above a threshold, they turn ON other core
>      * Both cores run at same Operating Point once ON
>  * Debug info in common clk API being discussed upstream by Jeremy
>    * There is currently no debug info
>    * clock name is not part of the common struct clk to keep size down
>    * Need to engage with Jeremy
>    * Yong will test the patches from Jeremy on imx5 and report back
>  * Powerdebug: should we visualise the clock and power dependencies using
> information from /sys or debugfs?
>    * No immediate horror expressed at the idea
>    * Freescale and TI already do it to a certain extent by dumping the
> clock tree and rates into a table
>    * The entire tree is too complex to depict
>    * We could represent it in parts e.g. start at a peripheral and plot
> it's clock and power dependencies all the way up
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linaro.org/pipermail/linaro-dev/attachments/20100830/cd62292c/attachment.htm 


More information about the Linaro-dev mailing list