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

Hi Amit,

Thanx for the generous response :)

On Mon, Sep 6, 2010 at 12:58 PM, Amit Kucheria amit.kucheria@linaro.org wrote:

The currently proposed bindings are documented on the DeviceTree wiki[1]. Please understand that these are Device tree bindings, and it seems that we

Okay. This seems more like moving out the current platform regulator bindings to the dtb. Please correct me if I am wrong.

might not need a new framework to track power domains since a lot of the work is already handled by the regulator framework.

Just to be sure, by a power domain, I refer to the domain on a SoC or a CPU. The bindings which I see here are basically regulators on the board. But on most ARM SoCs available like OMAP, U8500, different peripherals are grouped into different power domains aka "SoC regulators".

I had a discussion with the regulator maintainers some time ago at http://lkml.org/lkml/2010/5/10/213

Based on the discussion, it felt that the current regulator framework cannot be moderated upon a the SoC power domain types. and hence my curiousity.

What are your interests?

The above thread holds most of the discussion that we had. My idea is like

- a generic framework that allows modelling of SoC power domains, hoping to integrate both clocks and regulators. There are platforms that dont implement DVS, hence a clock approach makes sense; A DVS only platfom has it easier to implement via regulators and so on.

- able to manage dependencies on power domains in terms of constraints from children to parent domains, ability to manage independent power state transitions via specific SoC configurations

Also, I am curious about few PM techniques that IMO can be exploited like Run time OPP management for peripherals based on use cases; like Hw accelerators that may run at half the voltage/clocking for reduced loads; storage devices running at reduced loads when the overall QoS parameters may signify a power-save mode vs performance mode etc.

Please do let me know of your views on the above.

Regards, Sundar