Ubuntu Touch Power Management

Registered by Tony Espy on 2013-03-20

Discuss requirements and possible architecture of system power management on Ubuntu Touch and converged Desktop.

Blueprint information

Status:
Started
Approver:
Loïc Minier
Priority:
Undefined
Drafter:
Tony Espy
Direction:
Approved
Assignee:
None
Definition:
Pending Approval
Series goal:
Accepted for saucy
Implementation:
Slow progress
Milestone target:
None
Started by
Tony Espy on 2013-03-25

Related branches

Sprints

Whiteboard

The current Ubuntu Touch images use a glib/C-based power daemon which currently provides shutdown and suspend initiated by power button events.

https://code.launchpad.net/~phablet-team/powerd/trunk

Other features considered, but not yet implemented in powerd include:

 * auto screen dimming
 * auto shutdown on low battery/critical CPU temp
 * auto suspend on inactivity ( this conflicts w/wake_lock model )

Other topics that may be discussed include:

 * Usage of kernel & userspace wake locks
  * related to application life-cycle; wake locks are not exposed
 * Possible usage of upower?
  * prototype of powerd exists that uses upower, however upower has dependencies that we might not want to bring in.
 * Desktop plans of gnome-settings-daemon
 * CPU Frequency scaling
 * Power controls

Question: how does an application handle being able to do things long-running ( i.e. like a service ).

Discussion about whether devices ever go into full S3.

powerd is very small, and tries to keep it's dependencies minimal, and therefore it's very device specific. Is the goal we re-write for every device, as it's not configurable.

Mike: it is generic ( at least the input handling part; it's using Mir's input handling ).

All of the suspend/resume functionality has moved into systemd/logind. It supports suspend inhibitors. It uses pm-utils, although this could be dropped. It already listens to power button events ( not the greatest idea... as it breaks the plumbing/policy model ). logind provides a high-level DBus API to provide the APIs ( Suspend, CanSuspend ). It combines user/session tracking functionality of ConsoleKit with the functionality of upower. This seems to be right direction.

Is it appropriate to move this to logind, and change powerd to implement the policy side?

Is there anything from Desktop that we could use for power policy?

Using gnome-settings-dameon is a non-starter because it is deemed too heavy. Probably a better idea to start writing a small policy daemon from scratch (glib is OK).

We could put the policy in the indicator-power service. There's been some talk that the GNOME developers might move the remaining upower logic (battery profiling and watching for batteries going low) into g-s-d's power plugin, so putting ours into indicator-power would fit well. It should be able to grok current Desktop settings as well as new settings for touch devices.

  * Android uses power_profile.xml files for battery information

We've patched logind to support pm-utils, but we can change that to not require pm-utils (we only need that for old desktop systems, not on mobile).

We haven't done detailed analysis of S3 on our devices. When we write mem to /sys/power/state, the device appears to go into S3 even when it may not. We're not sure how this works.
* Analysis: https://docs.google.com/a/canonical.com/document/d/1CMmRi5OaLmhZQ_W4Vfqfr6NxR0rskPcT64gPrmBvXeY

The Nexus4 does appear to go into S3.

For converged devices, we could auto-detect wake-locks.

We can implement policy that uses wake locks, or choose not to. Note, we need to do some competitive analysis to determine battery life of comparable devices as this will help us with the overall decision. Once we determine our battery life goals, it may not prove feasible to move to a userspace driver suspend model.

Can we create a wiki page where we can start documenting the S3/wake lock behavior.

Should we transition to powerd or we can migrate to something else?

We can migrate from powerd to logind. logind doesn't monitor Android's input stack, so we'll have to put listening for those input events into e. g. indicator-power. If we use Mir's input stack, then we're safe across form factors.

The question was asked whether or not there'll be any changes to the container model and how this could affect our approach(es). It also was pointed out that if we stick with the current model, that we need to solve the udev problem ( ie. the fact that we currently don't run in udev in our container, and if we do enable it, how do we manage this when ueventd, vold and netd are running ).

(?)

Work Items

Work items:
[mfrey] modify logind to support Touch-specific power plumbing: TODO
[larsu] implement power policy for Touch in indicator-power service: TODO
[larsu] Implement battery monitoring / auto-shutdown for low battery: TODO
[larsu] Implement critical temperature shutdown: TODO
[ogra] Investigate CPU frequency: TODO
[sforshee] Investigate current kernel S3 behavior on Touch: DONE
[awe] Investigate current usage of AOSP userspace wake locks: TODO
Investigate alternative userspace suspend model: TODO
[rsalveti] Investigate continued usage of wake locks: DONE
[rsalveti] Investigate device battery usage for Android, as some of the newer devices use device-specific kernel classes: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.