Wednesday, 29-09-2010




IRC Nick

Amit Kucheria


Amit Arora


Vishwanath Sripathy


Yong Shen


Vincent Guittot


Bobby Bhatacharia


Srinivas Kalaga


Robin Randhawa



Action Items from this Meeting

Action Items from Previous Meeting

  • ACTIVE (Immediate):
    • Vishwa: working to refactor assembly routines for save/restore/wfi: SENT to l-o
    • Vishwa: split up work items to be more granular: TODO
    • Yong: talk to FSL u-boot maintainer about missing features and ways to get them into mainline u-boot and linaro u-boot
    • Everyone: help testing linaro images
    • ACTION: ARM: results of using PMU counters for correlation to PM
    • ACTION: Amit K to spend some time on usecase to reproduce ondemand governor problems: POSTPONED
    • Amit K (added post meeting): looking into merging linux-pm branch for OMAP into Linaro
    • 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: 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


  • PM QA work
    • PMU counters for QA work
      • cache misses, TLB misses impact memory -> hence corelation to power

      • ARM to provide more information on their results
    • track wakeups in relation to idle state
      • what idle state did we wakeup to?
      • what idle state did we goto retention/off from?
      • powertop tells us about residency in various idle states - is that enough?
    • Board power consumption will be very high if optimisations are not in mainline
      • measure only cpu current?
        • Changes in board current might not be easily visible
        • omap3 beagle, i.MX51 babbage and U8500 have pads to measure cpu current alone
        • more effective in telling us about regressions in software stack
      • board consumption can also be measured and optimisation patches sent to mainline
    • Differentiate between programmed wakeups and spurious ones
      • How can we tell them apart?

WorkingGroups/PowerManagement/Meetings/2010-09-29 (last modified 2010-09-29 09:38:26)