PerSoCPowerManagement

Rationale

During the last development cycles the actual work time the ubuntu-armel team had available to do actual work on SoC specific images was only 3 months per SoC for various reasons. Due to this fact the focus wasnt put on things like power management or suspend/resume testing because there were more basic bringup issues to focus on. In the lucid cycle where we should have more time available due to better scheduling of the formerly blocking issues the plan is to change this lack and have proper power management support in place for all supported SoCs by release.

Scope

We will have all power saving as well as suspend/hibernate/resume properly working on all hardware that is supposed to support these features. Vendors will be contacted to provide lists of which features are supposed to work on their hardware and how much power a board should consume. Ubuntu will be adjusted to match or at least get as colse as possible to these targets.

Implementation

The focus of the implementation will be to consume as less power as possible for each board with SSD media attched and to get as close as possible towards the reference numbers the vendors provide.

  • Kernel
    • The in-kernel regulators and power management features will be reviewed closely on a per SoC basis and fixed where not fully functional
    • Suspend/Hibernate/Resume functionality will be reviewed closely on a per SoC basis and fixed where not fully functional
    • SoC kernels should be optimized for SSD usage
    • Check proper cpufreq wakelocks and pmqos integration
  • Userspace
    • pm-utils will get a review with regard to the armel architecture (many/most scripts in DevicekitPower are untested on armel and focus on x86 hardware)

    • where needed work out policies that will be enabled on a per architecture basis
    • disable unused pm-utils scripts at package build time on armel
  • Hardware measuring
    • In parallel to software measuring we will do use general voltmeters to measure the power consumption
    • Use a standardized kit across the team to do this kind of measurement

Test cases

  • Different test cases we will cover and measure
    • idle board without X running
    • idle at full desktop
    • suspended board
    • power consumption during video playback
    • power consumption during audio playback
    • power consumption with and without wifi enabled
    • Make sure that all hardware that was shot down in a suspend/hibernate task gets brought up on resume again.

Open issues

SSD hardware needs to be shipped to at least one of the SoC maintainers for each SoC

Some vendors have binary-only solutions which we can not measure or take into account

Specs/Mobile/ARM/PerSoCPowerManagement (last edited 2009-11-30 12:32:35 by p5098ed03)