Introduction

The PM WG has been asked to draft a plan to catch power management-related issues on various partner platforms. This document is meant to spur discussion and highlight the requirements of such a QA process. After those requirements are known, we can estimate the resourcing required.

To start with, I propose we measure wakeups per second on the Linaro stack and if desired, add board current consumption to that. Wakeups per second should be roughly comparable across various boards, while board current consumption cannot be compared due to the variety of peripherals and configurations possible.

While testing with various UI heads will be of great interest to the partners, I believe that starting with wakeups and board current measurement on headless images will allow us to build the infrastructure needed while keeping complexity down.

Assumptions

  • Done on Enhanced Headless images - supplies the baseline power consumption for the HW platform
  • Need for automation - we need infrastructure to boot various partner platforms and run automated tests to enhance reproducibility
  • Weekly/Bi-weekly testing (sync with Linaro milestones)

What is tested?

  • Implementation of various PM interfaces (e.g. cpufreq, cpuidle, clock debug, regulator debug, etc.) tested at runtime on the partner's platforms
  • Wake ups per second
  • If desired, Board current consumption1

Tools needed

  • Tool to test availability of various PM interfaces (cpuidle, cpufreq, debug interfaces) in a partner's kernel at runtime.
    • Could be adopted from powertop
  • Enhanced headless images containing some useful applications for testing - music player, network connectivity daemon, etc.
  • Test harness - for automation
  • Boards in DC connected to lab power supplies - these should allow remote control and measurements. We could start with local boards, but eventually this should be moved to the DC.

Interesting use cases

Ref.

Test

Pre-condition

Measurements

Wakeups per second

Board Current

QA-1

Idle use cases

QA-1.1

Idle after boot

Boot up after default install, wait a minute to let the system settle (disk, network, etc.)

x

QA-1.2*

Idle after resume from suspend

Suspend board, resume, wait a minute to let the system settle

x

QA-1.3*

Idle after resume from hibernate

Hibernate, resume, wait a minute to let the system settle

x

QA-2

Activity use cases

QA-2.1

Music playback (from disk)

Start pre-decided music file

x

QA-2.2

Music playback (from network)

Start music stream over network (wlan or ethernet)

x

QA-2.3

Measure 'efficiency' of cpufreq and cpuidle

Some test to exercise C-state/P-state transitions

x

Testing methodology

  • Typical tests should last 30-60s to encapsulate most low-level periodic wakeups2.

  • For current measurements, boards should be powered by a lab power supply that can measure current (preferably allows the values to be read programatically).

TODO

  • select the subset of the software stack that is used to perform the tests
  • describe the usecases to be tested
  • establish the baselines (wakeups/sec, idle current consumption, etc.) on the various partner boards
  • howto help debug problems when they're found

Appendix

  1. Since each board is unique and requires several tweaks to get to lowest power consumption, this will require help from experts from partner companies to verify if we have reached those levels (1)

  2. Longer tests can be considered if we have certain applications that have much longer cycles of periodic activity (2)

WorkingGroups/PowerManagement/Archives/PmwgQaPlan (last modified 2013-08-22 07:14:56)