Power management requirements

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(catchg)
 
(One intermediate revision by one user not shown)
Line 50: Line 50:
 
* [[User:CesarB/Requirements]]
 
* [[User:CesarB/Requirements]]
  
[[Category:Documentation]]
+
[[Category:Low-level software]]
 +
[[Category:Hardware]]
 +
[[Category:Battery]]

Latest revision as of 09:28, 19 July 2009

Here are some non-specific requirements for Openmoko regarding power management of the phone. There are three general classes of requirements:

  1. The phone should take the necessary actions for the battery never to run too empty.
  2. The phone should save power as much as possible to keep run times as long as possible.
  3. The phone should keep the user informed of power management state and events.

Like so many requirements, we would want more than is possible in theory or than is possible in practise with our resources. Like in all design, trade-offs have to be made between various desirable properties. For details about the hardware and drivers, and what's actually possible, see Neo1973 GTA01 Power Management. An important part of the implementation regarding management is being able to follow the charge state accurately and to forecast what the state is in say 10 minutes. This is made more difficult by battery aging.

Contents

[edit] Battery level maintenance

Here the trade-off is between system simplicity and using all the power we get versus being easy to use and tolerant to "user errors". It's actually always possible that we lose all charge due to the small current drawn even while the system is fully off, but we can make this a very special corner-case.

Battery is too empty if:

  1. the battery is damaged for being too empty (this is taken care of by the battery itself).
  2. we are not able to start uboot to show the user messages about charging and to negotiate the 500 mA fast charge mode when available.
  3. we can't shut down the phone cleanly and have enough power left to get back to the boot loader.

We need to have separate checks for these cases:

  1. The system is fully operational and we need to shut it down cleanly. (Bug #847: Shutdown if battery level goes too low)
  2. The system is in a sleep mode and we need to wake it up so that it can be shut down cleanly.
  3. The system is off and we need to stop the user from accidentally booting it if we couldn't shut it down cleanly. (Bug #848: A charger mode for uboot)

[edit] Power saving

Here the trade-off is between system simplicity and responsiveness and quality of all features versus longer run-times without the need to charge. Typically the return from a slow-power mode is not instant and the user will have to wait a moment (short or long).

Power saving options we have in general:

  1. Keep subsystems powered down when they are not needed. (Bug #770: Battery discharging while phone is off (GSM part), Bug #842: Whenever possible, Amp Mode should be Off, Bug #1003: GSM modem is not powered down when Linux is shut down)
  2. Use suspend-to-ram sleep when we don't need to control any subsystems with the CPU.
  3. Use lower operational modes: dimmer screen, slower CPU frequency.

[edit] Informing the user

This is easier the more we can hide the details from the user in the previous sections.

Things the user needs to know:

  1. Warning tone during a call when there is little time left.
  2. How much power is left? How long does it last?
  3. How quickly are we charging?
  4. The screen went black, what happened? My phone doesn't turn on, what's going on?
  5. How can I make the battery last longer?

Challenges:

  1. We can only measure battery voltage not actual charge, and batteries age in time.
  2. If we don't have enough power to turn on the CPU and the screen how do we communicate with the user?
  3. The user has almost zero technical knowledge.

[edit] See also

Personal tools

Here are some non-specific requirements for Openmoko regarding power management of the phone. There are three general classes of requirements:

  1. The phone should take the necessary actions for the battery never to run too empty.
  2. The phone should save power as much as possible to keep run times as long as possible.
  3. The phone should keep the user informed of power management state and events.

Like so many requirements, we would want more than is possible in theory or than is possible in practise with our resources. Like in all design, trade-offs have to be made between various desirable properties. For details about the hardware and drivers, and what's actually possible, see Neo1973 GTA01 Power Management. An important part of the implementation regarding management is being able to follow the charge state accurately and to forecast what the state is in say 10 minutes. This is made more difficult by battery aging.

Battery level maintenance

Here the trade-off is between system simplicity and using all the power we get versus being easy to use and tolerant to "user errors". It's actually always possible that we lose all charge due to the small current drawn even while the system is fully off, but we can make this a very special corner-case.

Battery is too empty if:

  1. the battery is damaged for being too empty (this is taken care of by the battery itself).
  2. we are not able to start uboot to show the user messages about charging and to negotiate the 500 mA fast charge mode when available.
  3. we can't shut down the phone cleanly and have enough power left to get back to the boot loader.

We need to have separate checks for these cases:

  1. The system is fully operational and we need to shut it down cleanly. (Bug #847: Shutdown if battery level goes too low)
  2. The system is in a sleep mode and we need to wake it up so that it can be shut down cleanly.
  3. The system is off and we need to stop the user from accidentally booting it if we couldn't shut it down cleanly. (Bug #848: A charger mode for uboot)

Power saving

Here the trade-off is between system simplicity and responsiveness and quality of all features versus longer run-times without the need to charge. Typically the return from a slow-power mode is not instant and the user will have to wait a moment (short or long).

Power saving options we have in general:

  1. Keep subsystems powered down when they are not needed. (Bug #770: Battery discharging while phone is off (GSM part), Bug #842: Whenever possible, Amp Mode should be Off, Bug #1003: GSM modem is not powered down when Linux is shut down)
  2. Use suspend-to-ram sleep when we don't need to control any subsystems with the CPU.
  3. Use lower operational modes: dimmer screen, slower CPU frequency.

Informing the user

This is easier the more we can hide the details from the user in the previous sections.

Things the user needs to know:

  1. Warning tone during a call when there is little time left.
  2. How much power is left? How long does it last?
  3. How quickly are we charging?
  4. The screen went black, what happened? My phone doesn't turn on, what's going on?
  5. How can I make the battery last longer?

Challenges:

  1. We can only measure battery voltage not actual charge, and batteries age in time.
  2. If we don't have enough power to turn on the CPU and the screen how do we communicate with the user?
  3. The user has almost zero technical knowledge.

See also