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.sripa...@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.kuche...@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@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > >
powertop_test.log
Description: Binary data
powertop_omap.patch
Description: Binary data
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
