I had missed some observation in previous testing. Apologies for that. I noticed that if I sum up C state average residency, it is not summing up to 100%. Also some of the C state average residency seems to be not correct. Attached is the log and changes I have done on top of latest powertop code to cross compile it for OMAP.
Regards Vishwa
On Mon, Aug 30, 2010 at 11:30 AM, Vishwanath Sripathy < vishwanath.sripathy@linaro.org> wrote:
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@linaro.orgwrote:
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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev