Neo 1973 GTA01 Power Management
From Openmoko
(Difference between revisions)
m |
Liane shen (Talk | contribs) (revert & delete spam) |
||
| Line 1: | Line 1: | ||
| − | + | Power management is of utmost concern to any mobile device. Battery power is quite limited, so we need to make sure we try our best to conserve it. The [[Neo1973 Power Management |Neo1973 Power Management page]] tries to describe the various power management features of the [[:Category:Neo1973 Hardware | Neo1973 Hardware]], their states, transitions, etc. First, we start by describing the power states of the individual hardware components. Then we look at it from a System Integration point of view. | |
| Line 59: | Line 59: | ||
=== NOPOWER === | === NOPOWER === | ||
| − | Condition: Vbat < Vverylowbat | + | Condition: Vbat < Vverylowbat && Vback < Vlowback && Vchgvin < Vlowchg |
| + | |||
| + | Human-Readable: If main battery voltage < 2.7V and backup battery voltage < 1.3V and charger voltage < 2.7V | ||
| + | |||
| + | === SAVE === | ||
| + | |||
| + | Condition: Vbat < Vverylowbat && (Vback > Vlowback || Vchgvin > Vlowchg) | ||
| + | |||
| + | Human-readable: If main battery voltage < 2.7V and at least backup battery voltage > 1.3V or charger voltage > 2.7V. | ||
| + | |||
| + | === STANDBY === | ||
| + | |||
| + | Condition: Vbat > Vverylowbat | ||
| + | |||
| + | Human-readable: If main battery voltage > 2.7V | ||
| + | |||
| + | === ACTIVE === | ||
| + | |||
| + | Condition: Vbat > Vlowbat | ||
| + | Human-Readable: If main battery voltage > 2.8V (configurable up to 3.4V) | ||
| + | Transition from STANDBY to ACTIVE: If ONKEY button is pressed, or RTC Alarm, or EXTON or charger insert or pen-down by touchscreen (we don't use the PMU TS controller) | ||
| + | |||
| + | == JBT6K74 LCM == | ||
| + | |||
| + | === Deep Standby === | ||
| + | |||
| + | In this mode, only the supply power is activated | ||
| + | |||
| + | === Sleep === | ||
| + | |||
| + | Holds register data with clock stopped | ||
| + | |||
| + | === Normal === | ||
| + | |||
| + | Fully powered up and operational | ||
| + | |||
| + | == System Level == | ||
| + | |||
| + | This is a description of the system-level power management. | ||
| + | |||
| + | === System Power states === | ||
| + | |||
| + | In order to do system-level power managment, we need to introduce state definitions with their according state names. The state names are prefixed by SYS_POWER_. | ||
| + | |||
| + | ==== SYS_POWER_NO ==== | ||
| + | |||
| + | In this state, there is no main battery and no USB charger voltage applied. However, the backup battery is supposed to be operational. | ||
| + | |||
| + | * PCF50606: SAVE | ||
| + | * S3C2410: unpowered | ||
| + | * JBT6K74: unpowered by PMU | ||
| + | * GSM: unpovered because no Vbatt | ||
| + | * GPS: unpowered by PMU | ||
| + | * Bluetooth: unpowered by PMU | ||
| + | * Backlight: powered off | ||
| + | |||
| + | ==== SYS_POWER_OFF ==== | ||
| + | |||
| + | This is the regular, "switched off" state of the device. The device does not provide any functionality. | ||
| + | |||
| + | * PCF50606: STANDBY | ||
| + | * S3C2410: unpowered by PMU | ||
| + | * GSM: Powered down by driving MODEM_ON to LOW | ||
| + | * GPS: unpowererd by PMU | ||
| + | * JBT6K74: unpowered by PMU | ||
| + | * Bluetooth: unpowered by PMU | ||
| + | * Backlight: powered off | ||
| + | |||
| + | ==== SYS_POWER_ON_FULL ==== | ||
| + | |||
| + | This is the regular, "fully switched on" state of the device, during user interaction. | ||
| + | |||
| + | * PCF50606: ACTIVE | ||
| + | * S3C2410: NORMAL | ||
| + | * GSM: Powered up by driving MODEM_ON to HIGH | ||
| + | * GPS: Depending usage / configuration | ||
| + | * Bluetooth: Depending usage / configuration | ||
| + | * JBT6K74: NORMAL | ||
| + | * Backlight: on (brightness according to PWM) | ||
| + | |||
| + | ==== SYS_POWER_ON_SCRSAVE ==== | ||
| + | |||
| + | This is the screen saver mode, if user doesn't interact with LCM for some time (SCRSAVE_TIMEOUT), default 30sec. | ||
| + | |||
| + | * PCF50606: ACTIVE | ||
| + | * S3C2410: SLOW or IDLE | ||
| + | * GSM: Powered up by driving MODEM_ON to HIGH | ||
| + | * GPS: Depending usage / configuration | ||
| + | * Bluetooth : Depending usage / configuration | ||
| + | * JBT6K74: SLEEP | ||
| + | * Backlight: powered off | ||
| + | |||
| + | ==== SYS_POWER_SLEEP ==== | ||
| + | |||
| + | This is the power saving mode, if user doesn't interact with LCM within SLEEP_TIMEOUT after SYS_POWER_ON_SCRSAVE was entered, default 30sec. | ||
| + | |||
| + | * PCF50606: ACTIVE | ||
| + | * S3C2410: Power_off (this is the suspend-to-RAM state) | ||
| + | * GSM: Powered up by driving MODEM_ON to HIGH | ||
| + | * GPS: TBD | ||
| + | * Bluetooth: Powered down by PMU | ||
| + | * JBT6K74: Deep Standby | ||
| + | * Backlight: powered off | ||
| + | |||
| + | === Wake-up reasons === | ||
| + | |||
| + | In the following events, we want the main CPU to be able to be woken up from Power_off (SYS_POWER_SLEEP) state: | ||
| + | |||
| + | ==== Events from GSM ==== | ||
| + | |||
| + | * Incoming phone call | ||
| + | * Incoming SMS | ||
| + | * Loss of network signal | ||
| + | |||
| + | ===== Implementation ===== | ||
| + | |||
| + | The GSM daemon configures the GSM Modem in a way to only report the required unsolicited result codes to the UART. The CPU then needs to wake-up as soon as characters arrive at the UART. | ||
| + | |||
| + | {{note|The S3C2410 cannot resume from Power_off on UART input data. We need to connect either RTS/CTS to EINT, or send some other signals via GSM Modem GPIO to the EINT[0..15] pins of the S3C2410}} | ||
| + | |||
| + | ==== Button Press ==== | ||
| + | |||
| + | If somebody pushes either the [[Neo1973 Aux Button]] or the [[Neo1973 Power Button]], the system shall wake up | ||
| + | |||
| + | ===== Implementation ===== | ||
| + | |||
| + | ====== Power Button ====== | ||
| + | During suspend, the PMU is configured to allow PWRONF events to generate interrupts to the CPU. | ||
| + | |||
| + | {{note|Currently, the PMU IRQ is connected to EINT16, i.e. an interrupt source that cannot wake-up from Power_off mode!}} | ||
| + | |||
| + | ====== 911 Button ====== | ||
| + | The 911 button is connected to a EINT source that can wake-up the CPU from Poewer_off. | ||
| + | |||
| + | This means that resuming on 911 button will work out-of-the-box | ||
| + | |||
| + | ==== Charger Events ==== | ||
| + | |||
| + | If a charger plug (or any other USB device) is connected, the device shall resume and update the battery [charger] status. Also, charger errors such as over/undervoltage, over/under-temperature shall be reported. | ||
| + | |||
| + | ===== Implementation ===== | ||
| + | During suspend, the PMU is configured to allow EXTONR,CHGERR and related events to generate interrupts to the CPU. | ||
| + | |||
| + | {{note|Currently, the PMU IRQ is connected to EINT16, i.e. an interrupt source that cannot wake-up from Power_off mode!}} | ||
| + | |||
| + | |||
| + | == Voltages == | ||
| + | |||
| + | === VB === | ||
| + | |||
| + | * Battery terminal voltage | ||
| + | * Used by | ||
| + | ** [[LM4857]] Amplifier | ||
| + | ** [[PCF50606]] PMU | ||
| + | ** LCM Backlight | ||
| + | ** U7607 AVDD regulator | ||
| + | ** U7608 VTXCO_2V8 regulator | ||
| + | |||
| + | === CORE_1V8 === | ||
| + | This is the S3C2410 Core Voltage | ||
| + | |||
| + | * Generated by PMU DCUD | ||
| + | |||
| + | === IO_3V3 === | ||
| + | |||
| + | * Generated by PMU DCDE | ||
| + | * Used by | ||
| + | ** Vibrator | ||
| + | ** FLASH_3V3 (see below) | ||
| + | ** Touch panel transistors | ||
| + | ** S3C2410 VDDA_ADC | ||
| + | ** S3C2410 VDDOP | ||
| + | ** S3C2410 VDDMOP | ||
| + | ** S3C2410 nBATT_FLT | ||
| + | ** U1502 (latch for GSM UART) | ||
| + | ** S3C2410 EXTCLK ??? | ||
| + | ** SDRAM | ||
| + | |||
| + | === GL_3V3 === | ||
| + | |||
| + | * Generated by PMU DCDF | ||
| + | |||
| + | * Used by | ||
| + | ** AGPS | ||
| + | |||
| + | * Controlled by | ||
| + | ** PMU | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * Switch on/off if GPS is used or not | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * disabled by u-boot PMU initialization | ||
| + | |||
| + | === CODEC_3V3 === | ||
| + | |||
| + | * Generated by PMU IOVDD | ||
| + | |||
| + | * Used for | ||
| + | ** Audio Codec (digital and analog) | ||
| + | |||
| + | * Controlled by | ||
| + | ** PMU Driver | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * mostly included in ASoC, right? | ||
| + | * switch on, only if Audio path is required. | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * disabled by PMU initialization in u-boot | ||
| + | |||
| + | === LCM_3V3 === | ||
| + | |||
| + | * Generated by PMU LPVDDD | ||
| + | |||
| + | * Used by | ||
| + | ** Headset/GSM Uart Latch | ||
| + | ** LCM | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * check whether we really need to switch this off, since LCM has sophisticated PM features | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * enabled by u-boot PMU initialization | ||
| + | |||
| + | === BT_3V15 === | ||
| + | |||
| + | * Generated by PMU D1REG | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * has to be powered up before Bluetooth can be used | ||
| + | * Bluetooth device automatically enumerates at bus | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * disabled by u-boot PMU initialization | ||
| + | |||
| + | === GL_2V5 === | ||
| + | |||
| + | * Generated by PMU D2REG | ||
| + | |||
| + | * Used by | ||
| + | ** AGPS | ||
| + | |||
| + | * Controlled by | ||
| + | ** PMU Driver | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * switch on only in case GPS is enabled | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * disable by u-boot GPIO initialization | ||
| + | |||
| + | === USER1 === | ||
| + | |||
| + | FIXME: no idea what this is for | ||
| + | |||
| + | * Generated by PMU D3REG | ||
| + | |||
| + | ==== PMU Driver ==== | ||
| + | |||
| + | * permanently disabled | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * disabled by PMU initialization in u-boot | ||
| + | |||
| + | === FLASH_3V3 === | ||
| + | |||
| + | * Derived from IO_3V3 | ||
| + | |||
| + | * Used by | ||
| + | ** NAND Flash | ||
| + | |||
| + | * Controlled by | ||
| + | ** SD_EN GPIO | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * do we really want to switch it on/off before every flash access? | ||
| + | * if we go to standby, IO_3V3 will be switched off, thus FLASH_3V3 is off, too | ||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * on, enabled by u-boot GPIO initialization | ||
| + | |||
| + | === AVDD === | ||
| + | |||
| + | * Generated by U6707 | ||
| + | |||
| + | * Used by | ||
| + | ** AGPS | ||
| + | |||
| + | * Controlled by | ||
| + | ** EN_AGPS3V GPIO | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * Switch on only if GPS enabled | ||
| + | |||
| + | === VTCXO_2V8 === | ||
| + | |||
| + | * Generated by U7608 | ||
| + | |||
| + | * Used by | ||
| + | ** AGPS | ||
| + | |||
| + | * Controlled by | ||
| + | ** EN_GPS2V8 GPIO | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * enable only if GPS is used. | ||
| + | |||
| + | ==== Initial State ==== | ||
| + | |||
| + | * disabled by u-boot GPIO initialization | ||
| + | |||
| + | === SD_3V3 === | ||
| + | |||
| + | * Derived from IO_3V3 | ||
| + | |||
| + | * Used by | ||
| + | ** microSD slot | ||
| + | |||
| + | * Controlled by | ||
| + | ** SD_ON GPIO | ||
| + | |||
| + | ==== PM Driver ==== | ||
| + | |||
| + | * we don't want to switch this off while mounted, do we? | ||
| + | |||
| + | |||
| + | ==== Initial state ==== | ||
| + | |||
| + | * probably disabled, unless somebody uses 'mmcinit' from u-boot | ||
| + | * but we can't disable it without disabling NAND. | ||
| + | * result: enabled by u-boot GPIO initialization | ||
| + | |||
| + | == Kernel API == | ||
| + | |||
| + | == Userspace API == | ||
| + | |||
| + | == Approximate power draw of various subsystems == | ||
| + | |||
| + | The battery has a total of 1200mAh, at 3.6V. This is approximately 3500mWh, once power supply losses are taken into account. The figues below are estimates from datasheets. | ||
| + | |||
| + | These do not take into account the severe hardware bugs of phase 0 hardware, which severely affect power use. | ||
| + | |||
| + | * LCD | ||
| + | ** 200mW with backlight at full brightness | ||
| + | ** 40mW with backlight at 10% | ||
| + | *** Based on similar 2.8" LCDs. | ||
| + | * CPU | ||
| + | ** 320mW @ 200MHz | ||
| + | ** 450mW @ 266MHz | ||
| + | ** 140mW @ 200MHz idle. | ||
| + | ** 50mW @ 12MHz (slow mode) | ||
| + | *** These include fudge factors for RAM and other systems, from the CPU datasheet. | ||
| + | * Bluetooth | ||
| + | ** 63mW @ Tx Burst (file transfer, send) | ||
| + | ** 36mW @ Rx Burst (file transfer, receive) | ||
| + | ** 3.6mW @ Idle, beacon only | ||
| + | *** Based on the datasheets provided | ||
| + | * GSM ? | ||
| + | *** All GSM terminals have a 2W radio trasmitter so I believe Tx burst consumption will be under that while Rx burst and idle values should be in the 30mW range. | ||
| + | * GPS | ||
| + | ** 45mW | ||
| + | *** Based on comparison with a broadly similar (though not as fully featured chip [http://www.maxim-ic.com/appnotes.cfm/an_pk/3447 from Maxim] | ||
| + | |||
| + | USB does not work in slow mode, nor does the LCD screen controller. | ||
| + | It is not impossible that there may be ways to draw on the screen through the SPI interface, but this has not been confirmed or documented. | ||
| + | As bluetooth is connected via an internal USB connector, this will not work either. | ||
| + | |||
| + | This would imply that with the CPU constantly on in low power mode, GPS and GSM blipping on and off, and display off, the worst case power consumption is probably around 70mW, leading to a battery life of 2 days. | ||
| + | If the CPU is turned off, battery life rises significantly. | ||
| + | |||
| + | With everything on, playing video with sound, for example should get well over 4 hours. | ||
| + | |||
| + | == Measured power draw on phase 0 neo1973 == | ||
| + | |||
| + | I played with old ampermeter, old nokia 3110 (as a powersupply) and phase0 neo1973 a bit. It appears to eat 1.02 mW while powered off, 1.02W while booted (backlight on), ~0.51W while sleeping (with backlight on) and 1.4W while loading applications. | ||
| + | |||
| + | [[Category:Hardware]][[Category:Neo1973 Hardware]] | ||
Revision as of 06:36, 11 June 2007
Power management is of utmost concern to any mobile device. Battery power is quite limited, so we need to make sure we try our best to conserve it. The Neo1973 Power Management page tries to describe the various power management features of the Neo1973 Hardware, their states, transitions, etc. First, we start by describing the power states of the individual hardware components. Then we look at it from a System Integration point of view.
Contents
|
S3C2410 SoC
The S3C2410 SoC section is an overview of the S3C2410 power states or modes and their capabilities. The S3C2410 has the following modes:
Normal Mode
This is the most power-consuming mode. Regular operation at full clock speed (266MHz). The typical power consumption is 335mW in this mode.
We can dynamically reduce the CPU core clock speed to lower frequencies, if required.
Idle Mode
In this mode, FCLK to the CPU core is switched off. This reduces the power consumption to about half the typical 'Normal mode' consumption: 177mW
Wake-up sources
any interrupt.
Slow Mode
In slow mode, FCLK is tied to the external crystal, i.e. 12MHz in our case. The CPU core, SDRAM and bus clocks are also running at 12MHz.
This reduces the power consumption to typically 33mW.
Wake-up sources
none, we can just use our slowly running code to switch back to Normal mode, if it's required.
Power_off Mode
In Power_off mode, only the SDRAM is held in refresh, and the SoC-internal wake-up logic and RTC is powered. This means that the overall power consumption of the CPU goes down to max. 100uA, which translates to 200uW at 2.0V core voltage.
Wake-up sources
The number of wake-up sources is more restricted in this mode:
- EINT[0...15]
- RTC Alarm Interrupt
- nBATT_FAULT pin
System design considerations
In order to fully support Power_off mode, we need to
- Be able to switch off VDDi/VDDiarm/VDDi_MPLL/VDDi_UPLL separately from VDDalive, using a switch based on the PWREN signal
PCF50606 PMU
This is an overview of the PCF50606 power modes / state transitions
NOPOWER
Condition: Vbat < Vverylowbat && Vback < Vlowback && Vchgvin < Vlowchg
Human-Readable: If main battery voltage < 2.7V and backup battery voltage < 1.3V and charger voltage < 2.7V
SAVE
Condition: Vbat < Vverylowbat && (Vback > Vlowback || Vchgvin > Vlowchg)
Human-readable: If main battery voltage < 2.7V and at least backup battery voltage > 1.3V or charger voltage > 2.7V.
STANDBY
Condition: Vbat > Vverylowbat
Human-readable: If main battery voltage > 2.7V
ACTIVE
Condition: Vbat > Vlowbat Human-Readable: If main battery voltage > 2.8V (configurable up to 3.4V) Transition from STANDBY to ACTIVE: If ONKEY button is pressed, or RTC Alarm, or EXTON or charger insert or pen-down by touchscreen (we don't use the PMU TS controller)
JBT6K74 LCM
Deep Standby
In this mode, only the supply power is activated
Sleep
Holds register data with clock stopped
Normal
Fully powered up and operational
System Level
This is a description of the system-level power management.
System Power states
In order to do system-level power managment, we need to introduce state definitions with their according state names. The state names are prefixed by SYS_POWER_.
SYS_POWER_NO
In this state, there is no main battery and no USB charger voltage applied. However, the backup battery is supposed to be operational.
- PCF50606: SAVE
- S3C2410: unpowered
- JBT6K74: unpowered by PMU
- GSM: unpovered because no Vbatt
- GPS: unpowered by PMU
- Bluetooth: unpowered by PMU
- Backlight: powered off
SYS_POWER_OFF
This is the regular, "switched off" state of the device. The device does not provide any functionality.
- PCF50606: STANDBY
- S3C2410: unpowered by PMU
- GSM: Powered down by driving MODEM_ON to LOW
- GPS: unpowererd by PMU
- JBT6K74: unpowered by PMU
- Bluetooth: unpowered by PMU
- Backlight: powered off
SYS_POWER_ON_FULL
This is the regular, "fully switched on" state of the device, during user interaction.
- PCF50606: ACTIVE
- S3C2410: NORMAL
- GSM: Powered up by driving MODEM_ON to HIGH
- GPS: Depending usage / configuration
- Bluetooth: Depending usage / configuration
- JBT6K74: NORMAL
- Backlight: on (brightness according to PWM)
SYS_POWER_ON_SCRSAVE
This is the screen saver mode, if user doesn't interact with LCM for some time (SCRSAVE_TIMEOUT), default 30sec.
- PCF50606: ACTIVE
- S3C2410: SLOW or IDLE
- GSM: Powered up by driving MODEM_ON to HIGH
- GPS: Depending usage / configuration
- Bluetooth : Depending usage / configuration
- JBT6K74: SLEEP
- Backlight: powered off
SYS_POWER_SLEEP
This is the power saving mode, if user doesn't interact with LCM within SLEEP_TIMEOUT after SYS_POWER_ON_SCRSAVE was entered, default 30sec.
- PCF50606: ACTIVE
- S3C2410: Power_off (this is the suspend-to-RAM state)
- GSM: Powered up by driving MODEM_ON to HIGH
- GPS: TBD
- Bluetooth: Powered down by PMU
- JBT6K74: Deep Standby
- Backlight: powered off
Wake-up reasons
In the following events, we want the main CPU to be able to be woken up from Power_off (SYS_POWER_SLEEP) state:
Events from GSM
- Incoming phone call
- Incoming SMS
- Loss of network signal
Implementation
The GSM daemon configures the GSM Modem in a way to only report the required unsolicited result codes to the UART. The CPU then needs to wake-up as soon as characters arrive at the UART.
| NOTE: The S3C2410 cannot resume from Power_off on UART input data. We need to connect either RTS/CTS to EINT, or send some other signals via GSM Modem GPIO to the EINT[0..15] pins of the S3C2410 |
Button Press
If somebody pushes either the Neo1973 Aux Button or the Neo1973 Power Button, the system shall wake up
Implementation
Power Button
During suspend, the PMU is configured to allow PWRONF events to generate interrupts to the CPU.
| NOTE: Currently, the PMU IRQ is connected to EINT16, i.e. an interrupt source that cannot wake-up from Power_off mode! |
911 Button
The 911 button is connected to a EINT source that can wake-up the CPU from Poewer_off.
This means that resuming on 911 button will work out-of-the-box
Charger Events
If a charger plug (or any other USB device) is connected, the device shall resume and update the battery [charger] status. Also, charger errors such as over/undervoltage, over/under-temperature shall be reported.
Implementation
During suspend, the PMU is configured to allow EXTONR,CHGERR and related events to generate interrupts to the CPU.
| NOTE: Currently, the PMU IRQ is connected to EINT16, i.e. an interrupt source that cannot wake-up from Power_off mode! |
Voltages
VB
- Battery terminal voltage
- Used by
CORE_1V8
This is the S3C2410 Core Voltage
- Generated by PMU DCUD
IO_3V3
- Generated by PMU DCDE
- Used by
- Vibrator
- FLASH_3V3 (see below)
- Touch panel transistors
- S3C2410 VDDA_ADC
- S3C2410 VDDOP
- S3C2410 VDDMOP
- S3C2410 nBATT_FLT
- U1502 (latch for GSM UART)
- S3C2410 EXTCLK ???
- SDRAM
GL_3V3
- Generated by PMU DCDF
- Used by
- AGPS
- Controlled by
- PMU
PM Driver
- Switch on/off if GPS is used or not
Initial state
- disabled by u-boot PMU initialization
CODEC_3V3
- Generated by PMU IOVDD
- Used for
- Audio Codec (digital and analog)
- Controlled by
- PMU Driver
PM Driver
- mostly included in ASoC, right?
- switch on, only if Audio path is required.
Initial state
- disabled by PMU initialization in u-boot
LCM_3V3
- Generated by PMU LPVDDD
- Used by
- Headset/GSM Uart Latch
- LCM
PM Driver
- check whether we really need to switch this off, since LCM has sophisticated PM features
Initial state
- enabled by u-boot PMU initialization
BT_3V15
- Generated by PMU D1REG
PM Driver
- has to be powered up before Bluetooth can be used
- Bluetooth device automatically enumerates at bus
Initial state
- disabled by u-boot PMU initialization
GL_2V5
- Generated by PMU D2REG
- Used by
- AGPS
- Controlled by
- PMU Driver
PM Driver
- switch on only in case GPS is enabled
Initial state
- disable by u-boot GPIO initialization
USER1
FIXME: no idea what this is for
- Generated by PMU D3REG
PMU Driver
- permanently disabled
Initial state
- disabled by PMU initialization in u-boot
FLASH_3V3
- Derived from IO_3V3
- Used by
- NAND Flash
- Controlled by
- SD_EN GPIO
PM Driver
- do we really want to switch it on/off before every flash access?
- if we go to standby, IO_3V3 will be switched off, thus FLASH_3V3 is off, too
Initial state
- on, enabled by u-boot GPIO initialization
AVDD
- Generated by U6707
- Used by
- AGPS
- Controlled by
- EN_AGPS3V GPIO
PM Driver
- Switch on only if GPS enabled
VTCXO_2V8
- Generated by U7608
- Used by
- AGPS
- Controlled by
- EN_GPS2V8 GPIO
PM Driver
- enable only if GPS is used.
Initial State
- disabled by u-boot GPIO initialization
SD_3V3
- Derived from IO_3V3
- Used by
- microSD slot
- Controlled by
- SD_ON GPIO
PM Driver
- we don't want to switch this off while mounted, do we?
Initial state
- probably disabled, unless somebody uses 'mmcinit' from u-boot
- but we can't disable it without disabling NAND.
- result: enabled by u-boot GPIO initialization
Kernel API
Userspace API
Approximate power draw of various subsystems
The battery has a total of 1200mAh, at 3.6V. This is approximately 3500mWh, once power supply losses are taken into account. The figues below are estimates from datasheets.
These do not take into account the severe hardware bugs of phase 0 hardware, which severely affect power use.
- LCD
- 200mW with backlight at full brightness
- 40mW with backlight at 10%
- Based on similar 2.8" LCDs.
- CPU
- 320mW @ 200MHz
- 450mW @ 266MHz
- 140mW @ 200MHz idle.
- 50mW @ 12MHz (slow mode)
- These include fudge factors for RAM and other systems, from the CPU datasheet.
- Bluetooth
- 63mW @ Tx Burst (file transfer, send)
- 36mW @ Rx Burst (file transfer, receive)
- 3.6mW @ Idle, beacon only
- Based on the datasheets provided
- GSM ?
- All GSM terminals have a 2W radio trasmitter so I believe Tx burst consumption will be under that while Rx burst and idle values should be in the 30mW range.
- GPS
- 45mW
- Based on comparison with a broadly similar (though not as fully featured chip from Maxim
- 45mW
USB does not work in slow mode, nor does the LCD screen controller. It is not impossible that there may be ways to draw on the screen through the SPI interface, but this has not been confirmed or documented. As bluetooth is connected via an internal USB connector, this will not work either.
This would imply that with the CPU constantly on in low power mode, GPS and GSM blipping on and off, and display off, the worst case power consumption is probably around 70mW, leading to a battery life of 2 days. If the CPU is turned off, battery life rises significantly.
With everything on, playing video with sound, for example should get well over 4 hours.
Measured power draw on phase 0 neo1973
I played with old ampermeter, old nokia 3110 (as a powersupply) and phase0 neo1973 a bit. It appears to eat 1.02 mW while powered off, 1.02W while booted (backlight on), ~0.51W while sleeping (with backlight on) and 1.4W while loading applications.
