Hardware Power Domains: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Undo revision 194276 by 213.186.58.130 (Talk) undo vandalism - sholton)
(Removing all content from page)
Line 1: Line 1:
{{OLPC}} <noinclude>{{Translations}}</noinclude>

This is a description of the power distribution scheme for the XO laptop.

The [[Requirements]] page contains the user-facing requirements associated with Power Management.

Please feel free to add information. Links to cited documents would be useful...

=Mass Production=

The power distribution scheme for mass production models (C2) is identical to the B3/B4 build, with minor changes to improve power dissipation.

We have a C2 machine wired up for power consumption measurements. A [[XO_Power_Diagram|diagram of the power distribution scheme]] is available.

[[Image:Tinderbox_C2.png|800px]]

=B3 Build=

[[Media:Tinderbox_B3.pdf| Diagram of the power distribution scheme for B3]]

The XO Laptop has three main power domains, corresponding to the three main states of the laptop:

* ''Off'' - In this state, a user considers the laptop powered off (the power light is turned off), yet elements, such as the embedded system controller or wireless mesh networking interface, may still be operating.

* ''Suspend'' - In this state, the laptop continues to display an image but is mostly powered down to conserve power. It may awake in milliseconds.

* ''Awake'' - In this state, all laptop components are fully powered on.

<i>Is this all ? The hardware enables other states: e.g. a deep sleep without the DCON being enabled, or with the DCON enabled but the LCD disabled.</i>

Some devices can be powered off independently of the above three states. E.g. power to the SD card can perhaps be turned on/off by the CaFe chip; power to USB slots is probably controlled by the USB interface during enumeration, power to the backlight is controlled by the DCON, power to the audio amp is controlled by an enable. In general, the kernel and OFW should power down anything they aren't using. It may be useful to poll powered-off devices (USB and SD -- and keyboard/trackpad in B2 suspend) by powering them on occasionally to see if anybody's there.

== Powered Continuously (Green) ==

Devices in the ''green'' power domain are powered whenever the laptop has a power source (a sufficiently charged battery or mains input). They are even powered when a user considers the laptop "turned off" (the power light is not lit). The laptop components in this power domain are the embedded system controller, the wireless mesh networking interface, and the main battery charger.

The main battery charger is operational whenever the laptop is connected to the mains (wall power). It converts the variable DC input to a stable voltage (that provided by our battery pack, 6V). That <tt>VIN</tt> power rail is the root of the power distribution tree, and is powered either by the main battery charger or the main battery.

The embedded controller (EC) is the heart of the laptop power system. It is a small microprocessor which monitors the pushbuttons around the display screen (power, gamepad, scrollpad, and rotate), as well as communicating with the main battery and main battery charger. It manages the transition between laptop power states, enabling most voltage regulators and switches.

If there is sufficient battery charge or mains input, the wireless mesh network interface will remain powered and operational. Thus the laptop continues to relay packets as a node on the [[Mesh Network Details| mesh network]]. The EC is responsible for notifying the wireless network interface of the current laptop power state and battery status. The EC is also notified when the network interface has received a packet addressed to the laptop.
Nothing in the ''yellow'' or ''red'' power domains is powered in the ''Off'' state. The CPU, Southbridge, main memory, keyboard/touchpad, and external USB devices are all powered off.

Power supplies in this domain are:
* 3VPCU, powering the embedded controller
* WLAN_3.3V, controlled by WLAN_EN (GPIO01 on the embedded controller), powering the wireless network interface.

If the input power drops below a preset voltage, the mesh network interface is disabled and the embedded controller is put into a reset state. This happens when a laptop battery is completely discharged and there is no mains input. A particularly difficult task is [[Hand Crank Low Battery Recovery|recovery from a low battery using only the hand crank]].

== Powered in Suspend (Yellow) ==

Devices in the ''yellow'' power domain are powered when the laptop is in the ''Suspend'' state (and when it is awake). In this state, the CPU and most of the Southbridge are powered down, but an image is maintained on the display, and the contents of SDRAM memory are preserved. All devices in the "green" power domain are also powered in the "Suspend" state. The system can resume to an ''Awake'' state in milliseconds, without the user even being aware that it was in the ''Suspend'' state.

System elements which are in this domain include main SDRAM memory, the DCON (and its external memory), and the LCD panel.


Power supplies in this domain are:
* SUS_3.3V, controlled by VR_ON# (GPIO00 on the EC, active low), powering parts of the Southbridge.
* SUS_1.2V, controlled by VR_ON#, powering parts of the Southbridge.
* V_MEM, controlled by SUS_ON (GPIO1B on the EC), powering the SDRAM main memory (and needed for DCON_2.5V and +2.5V).
* DCON_2.5V, controlled by DCON_EN (GPIOED on the EC), powering the DCON memory and memory interface (and needed for DCON_1.8V, and LCD_1.8V).
* DCON_1.8V, powering the DCON core.
* LCD_1.8V, controlled by VDDEN (from the DCON), powering the LCD
* LCD_AVDD, controlled by VDDEN, powering the LCD
* VGL, controlled by VDDEN, powering the LCD
* VGH, controlled by VGH_EN (from the DCON) and VDDEN, powering the LCD

== Powered when Awake (Red) ==

Devices in the ''red'' power domain are powered when the laptop is fully awake. In this state, most of the laptop is operating.

Power supplies in this domain are:
* VCORE_CPU, controlled by MAIN_ON (GPIO1A on the EC), powering the core of the CPU, the Southbridge, and the CAFE ASIC.
* +3.3V, controlled by PWR_ON (generated by VCORE_CPU being stable), powers CPU and Southbridge I/O (and required for VCC_SD).
* +5V, controlled by PWR_ON, powers external USB and audio amplifier.
* +2.5V, controlled by PWR_ON, powering the memory interface on the CPU
* CAFE_2.8V, powering the CAFE chip
* VCC_SD, controlled by SD_ON (GPIO2 on the CAFE), powering the SD card slot.

== LCD Backlight ==

The backlight for the display is independent of any other power state on the machine. It may be powered when the laptop is in the ''Suspended'' or ''Awake'' modes, but is not necessarily powered in any state. The backlight power supply is enabled by the <tt>BACKLIGHT</tt> control signal from the DCON.

== Camera ==

The camera may optionally be powered, when the laptop is in the ''Awake'' state.
There are two supply voltages required, both enabled by the CAM_GPIO3 control signal (GPIO3 on the CAFE chip).

== RTC Clock ==

The real time clock on the laptop is maintained by a rechargeable silver oxide button cell. This supply (VDD_RTC) is supplied to the Southbridge. This power domain will remain powered even if otherwise the laptop is completely dead (no line in, and no main battery).

The button cell is recharged whenever the Laptop is ''Awake''. If the laptop remains "Off" or "Suspended" long enough, the clock will lose track of the time, even if the laptop's main battery is charged, and even if it's plugged into AC power. (How long does it take to drain the button cell? How long does the button cell take to recharge? Should the laptop set the alarm to briefly power itself on for a recharge, then go back to suspend or off, before this clock loses track of the time? This would provide unlimited longevity for the RTC.)

=B2 build=

[[Media:LaptopPowerB2.pdf| Diagram of the power distribution scheme for B2]]

There are some minor changes to the power distribution between the B2 and later builds of the XO. These changes support the change to a Geode LX processor and fix bugs detected in the B2 build.

The power domain differences between the B2 and B3 build are:
* B2 used a separate 1.2V power supply for the CAFE and the Southbridge. In B3, these were merged into the core supply for the Geode LX.
* In B2, two switches were used to control power to the external USB ports. In B3, a single current-limited soft switch provided for power on all external USB ports.
* The keyboard and touchpad are not powered during suspend in B2 machines, preventing them from being used to wake up the laptop.
* On unmodified B2 machines, an error in the DCONLOAD control signal between the Southbridge and the DCON causing glitches between suspend and resume.

The last two issues [[B2_Suspend_ECR|may be corrected]] on B2 machines.

=Individual Integrated Circuits=

==Geode GX==

===CPU Core===

The main way to save power is to execute the HLT instruction when appropriate. This is the ACPI C1 state. GX has a feature called "suspend on hlt", which is always enabled, and causes the CPU core to "suspend" on every hlt, saving power.

* Suspend-on-Halt can be turned on and off by MSR 1210: This is on by default, and there is really no reason to turn it off.
* SMIs can be turned off with MSR 1301: Turning SMIs off is dangerous, PCI config space is emulated through SMM code.
* Real stamp and time stamp counters can count (or not) during suspend - MSR 1900: These settings are set to the correct values for compliant operation. Changing these settings will mess up all sorts of things in the system that use the tsc for timing.

===Video===

* Flat panel power management around page 377 of Geode manual (VP offset 0x410). This doesn't actually save us any power, but we need to follow the correct sequence anyway to correctly power the output buffers communicating with the DCON.
* Graphics processor can be turned off
* The video refresh compression feature will conserve power (and bandwidth) at the expense of increased memory usage
* Power down the DAC (both analog and digital sections) with Video MISC register (video base + 50h)

===Other GX devices===

MSR offset 2004 in each MBus device enables or disabled Active Hardware Clock Gating for that particular MBus device.

*GLIU0: ("top" bus interface unit)
*GLIU1: ("bottom" bus interface unit)
*MC: (memory controller)
*GP: A0002004 (BLT engine)
*DC: (display controller)
*VP: C0002004 (video processor)

Display controller has 4 different clocks.

There is a 200-clock delay from self-refresh exit to first read command. See MSR 2000001a. Note that this is a DDR spec, not a Geode spec.

Power mode sensitivity counters - MSR. Some experimentation could be done with these.

The Memory Controller's GLD_MSR_PM (MSR) is set to 3, enabling hardware and software clock gating. Software clock gating is determined by bits 33..32 of the MSR. Bit 32 controls gating on Power Mode 0, bit 33 controls gating on Power Mode 1.

==5536 Companion Chip==

* Clock domain list on page 63 of 33238f_cs5536_ds.pdf
* Power management overview on p 79
* More info on page 169
-> Note that the sections mentioned are describing the software and hardware architecture that is present on a normal GX/5536 system with an Insyde-type BIOS. Various pieces described there are not applicable to OLPC with LinuxBIOS.

* CPU supports clock stop (this really just means suspend-on-HLT)
* No support for optional ACPI Sleep state S2
* No support for ACPI CPU states C3 and CT
-> the throttling registers are actually present in GX, and they are fully documented. There were some errata with the hardware, but throttling may still work properly in many cases.

===5536 hardware power states===

* FO (Full On) - all clocks always running (state after reset)
* AHCG (Active Hardware Clock Gating) - hardware automatically stops/starts clocks transparently
* Suspend on Halt - ACPI G0/S0/C1
* Sleep - ACPI G1/S1/C2
* Auto-refresh - DRAM kept "warm" (support for ACPI G1/S3 state)

===5536 Power domains===
* Working Domain: Vcore and Vio
** Includes everything not listed below
* Standby Domain: Vcore_vsb and Vio_vsb
** GPIO[31:24]
** GPIO input conditioning functions 6 and 7
** GPIO power management events 6 and 7
** MFGPT[7:6]
** Power Management Controller (PMC) Standby Controller and its I/O (WORKING, WORK_AUX, RESET_OUT)
** PMC Standby registers starting at PMS I/O Offset 30h.
* RTC Domain - Vbat
** Real Time Clock (always on)

* WORKING output controls Working domain power to system memory
* WORK_AUX output controls Working domain power to everything else

System starts in Full On state. Switch to AHCG state via
power management MSRs (section 6.18.1 page 526). Each
functional block has such an MSR at xxxx.2004h.

===5536 Power Management MSRs===

* GLCP_GLD_MSR_PM - enable AHCG
* There are 47 clocks that can be independently controlled on the 5536. Things like USB (13 different clocks), PCI, IDE, Audio, etc.

===Other 5536 tests===

The MSRs have several BISTs, for things like FPU internals, etc.


==DCON Chip==

Verbatim excerpts from the DCON spec:

'''Register 1 bits related to power'''

'''Bit 1: DCON Sleep Mode'''
One key to the power efficiency of the DCON is its ability to enter a low power state in which the LCD is completely turned off, and the local SDRAM frame buffer is set to self-refresh mode – this mode is known as DCON Sleep Mode (or just Sleep mode). Under normal circumstances, the DCON will automatically enter Sleep mode as a result of prolonged system inactivity. Specifically, if the Auto Sleep Mode bit is set, and Display Timeout Value video output frames have occurred without a DisplayLoad cycle occurring, or an ECPWRRQST arriving, then the DCON will set this bit, and enter Sleep mode automatically.

Alternately, there are occasions where the CPU will need to initiate entry into DCON Sleep Mode. In particular, the CPU should manually enter Sleep mode when the power switch selects “System Off”, when the lid switch is closed, or when a critically low battery level is detected. To enter Sleep mode, this bit should be written with a ‘1’.

Since the frame buffer is held in the low power self-refresh state while the DCON is in Sleep mode, the DCON is unable to process incoming DisplayLoad cycles. However, the DCONLOAD pin is not ignored. If the CPU requests a DisplayLoad cycle while the DCON is in Sleep mode, this sets an internal state known as DCONLOAD_MISSED. This state is used to “remember” that the data in the frame buffer is no longer consistent with the latest display frame. When the DCON exits Sleep mode after missing DCONLOAD, it will automatically blank the screen, and will generate a DCONLOAD_MISSED interrupt by driving DCONIRQ active forone scan line. This allows the CPU to rewrite the latest frame, and then clear the Video Blanking pin to paint the newest information on the screen.

Exiting Sleep mode may be performed either manually or automatically. Under normal circumstances, this bit will be cleared automatically upon arrival of an ECPWRRQST. In other words, pressing a key restores the video display independently of the host CPU, thus “instantly” turning on the display when a keyboard key, cursor button, or the touchpad has been activated (this masks the latency that would otherwise be required for the CPU to enable the display). Alternately, if desired, the CPU may exit Sleep mode and reinitiate display refresh by clearing this bit to 0.

'''Bit 2: Auto Sleep Mode'''
When this bit is set to 1, the DCON will automatically stop the display process after Display Timeout Value video frames have been output without system activity. Any time DCONLOAD is high, or when an incoming ECPWRRQST occurs, the internal display timeout register is automatically reset to the value in the Display Timeout Value register. If a Display Timeout occurs, the DCON will automatically enter Sleep mode by setting the DCON Sleep Mode bit to 1. When the Auto Sleep Mode bit is 0, the DCON will continue display refresh indefinitely, whether DisplayLoad cycles or ECPWRRQST occurs; in that case, Sleep mode may only be entered by writing to the DCON Sleep Mode bit.

'''Bit 3: Backlight Enable'''
Backlight enable is used to determine whether the LCD’s backlight should be turned on while the display is enabled – set this to 1 to turn on the backlight whenever the DCON is not in DCON Sleep Mode. Note that it is not necessary for a screen saver to turn Backlight Enable on and off, since setting this bit allows the backlight to be enabled and disabled automatically (if this bit is left cleared, the backlight will remain disabled whether or not the DCON is on DCON Sleep Mode). When the Backlight is enabled, the BACKLIGHT pin will actively be driven high, and the DBC pin will be driven with a PWM waveform with a duty cycle that matches the value contained in the Backlight Brightness register.

'''Bit 4: Video Blanking'''
Video blanking is used to display “black” on the screen, without affecting the contents of the DCON’s frame buffer, or the power state of the LCD. This feature is primarily used to determine whether the DCON should exit Sleep mode with the panel displaying data, or with the panel data masked off until the next DisplayLoad cycle. This is notably used by DCON itself. Since the DCON cannot record incoming DisplayLoad cycles while in Sleep mode, it will automatically set the VIDEO_BLANKING bit if DCONLOAD goes high while sleeping, thus ensuring that old data is not displayed upon wakeup. If this bit is written with a ‘1’, the panel will display “black”. If written with ‘0’, the current contents of the SDRAM frame buffer will be displayed on the screen.

'''Bits 9-11: DotClock Divider'''
In order to support minimum power drain, the DCON supports the ability to reduce the frequency of the panel interface DotClock. The value in this field specifies the crystal oscillator divisor minus one, to yield the system DotClock frequency – all video timings are derived from DotClock. If this field contains 0, DotClock will be equal to the crystal’s clock frequency, whereas a value of 7 will yield a DotClock of 1/8th the crystal frequency. Using 4X the 14.31818 MHz crystal, and with nominal programmed video timing parameters that yield a 50 Hz panel refresh rate, varying the DotClock divider alone will result in actual panel refresh rates of 50.00 Hz, 25.00 Hz, 16.67 Hz, 12.50 Hz, 10.00 Hz, 8.33 Hz, 7.14 Hz, or 6.25 Hz.

'''Register 8: Display Timeout Value'''
In order to save power, the DCON has the capability of automatically powering down the display outputs and entering DCON Sleep Mode. This register contains the number of output video frames before this automatic powerdown will occur – see the DCON Display Mode Register for more information on using this feature.

==CaFe Chip (Camera and Flash Enabler)==

Global register at offset 0x3004 can turn off individual module clocks to
SD, NAND, and CC. Also, that register has a "ClkRun Enable Set/Clear" bit pair

===SD Controller Section===

In principle (i.e. if the simplified SD spec is fully implemented), it will
be possible to gate the power to the SD card.

===Camera Controller Section===
The clock control register at offset 0x88 lets you turn off PIXCLK

Control 1 Register - offset 0x40 - has PWRDNEN to power down the controller.

The power to the external sensor is supposed to be controlled by a GPIO

===NAND Controller Section===

Assuming that the controller deasserts CE* after an access, the NAND FLASH
chips will automatically enter a low-power standby state (10 uA typical).

==Wireless Controller Chip==

A station (client) (STA) can be in one of the three power management (PM) modes:
* Active mode (stays in Awake state)
* Power Save (PS) mode (stays in either Awake or Doze state)
* Deep sleep mode

When firmware enters PS mode, a number of hardware blocks are turned off
(hardware MAC, baseband processor, and RF chip). A wakeup timer starts
that wakes up the WLAN device at the next expected beacon transmit time
from the AP. When in PS mode, the hardware bus interface to the host is
turned off, as well.

Deep sleep mode:

The host may put the WLAN subsystem in Deep Sleep mode, during which
the WLAN subsystem does not wakeup at all. The host sends a signal
through the GPIO to wakeup the WLAN subsystem. The wakeup mechanism is
interface-dependent.

* Wakeup semantics.

The firmware can be configured to wakeup the host under certain events.
The various conditions are:

- Reception of any broadcast or multicast data (0x1)

- Reception of any unicast data (0x2)

- Generation of any MAC event (0x4)

The host always wakes up if any of the events corresponding to the link
loss happens.

==KB3700 Embedded Controller Chip==

* Sleep State - 8051 program counter stopped
* Deep Sleep State - all internal clocks stopped (~10 uA for 144-pin version)
* But resetting the embedded controller hard-resets the system!
* Power consumption targets for 64-pin version: RUN: 12 mA, IDLE: 3 mA, STOP: 500 uA

===Clock domains===
* Flash - (16 MHz to 64 MHz)
* 8051/XBI - uses high clock (setting CLKCFG) 22~4 MHz (whatever that means)
* WDT - 32 kHz
* Other peripherals use low clock (CLKCFG), 8~2 MHz

CLKCFG register can dial down the clocks.

==AD1888 Audio Codec Chip==

* Unused channels can be disabled (it has more channels than the 2 we use)
* TBD need to read more about this chip

==Power management test plan (work in progress)==

This section should be moved to the power management software page.

Two issues:
# Design verification for Quanta
# Software to implement dynamic power management

===Hardware Setup===

* Measure input current with ammeter, or
* If possible, measure specific power domains with voltmeters across sense resistors.

TBD - determine whether such sense resistor test points are available.

===C1 test===

* Turn off unnecessary devices and disable most interrupts
* Wait for current to stabilize and record reading
* Setup RTC alarm to fire after N seconds
* Execute HLT instruction
* Record new current reading
* Verify that system wakes up after RTC alarm fires

TBD: do we need to test wakeup from other interrupt sources?

===TBD Add test sequences for other domains and states===

==ACPI power states (reference)==

This section is a brief summary of ACPI power states, for reference

===Global states===
* G0 - running
* G1 - suspended but system state is recoverable "quickly"
* G2 - off, requires reboot to start, but power supply is attached
* G3 - mechanical off, no wall power or main battery power (RTC battery possibly present)

===System states===
* G0/S0 - not sleeping
* G1/S1 - many clocks off, but state maintained inside devices
* G1/S3 - suspend to RAM - devices powered off, so their state must be saved in RAM (RAM must be powered)
* G1/S4 - suspend to disk (RAM not powered)
* G2/S5 - full reboot required. 32 kHz clock running.
* G3 - everything off, except optionally the RTC (mechanical off)

===CPU states===
* G0/S0/C0 - CPU actively executing instructions
* G0/S0/C1 - CPU halted (HLT), waiting for interrupt. Cache snoops working, so bus mastering is possible.
* G1/S1/C2 - Lowest CPU power state that maintains CPU internal context. No need for snooping because (per S1 rules) devices are inactive.
* G0/S0/CT - clock throttling (not supported by Geode)

===Device states===
==== PCI ====
(As per the Default Device Class Power Management Spec)
* D0 - Device is on and running
* D1 - This state is not defined and not used (Jordan says - I have never seen a PCI device that does D1)
* D2 - This state is not defined and not used (Jordan says - Dito)
* D3 - Device is off and not running. '''Device context is assumed lost'''.

==== USB ====

The USB interface in the Southbridge, and any external devices, are only powered when the device is in the ''Awake'' state. Power for external devices is enabled by driving the <tt>USB_VDD_EN_1</tt> and <tt>USB_VDD_EN_2</tt> (from the EC).

==== Other devices ====

* Most other on-board devices (i8402, graphics, southbridge gadets) are either on or off (so either D0 or D3 in ACPI speak).

[[Category:hardware]]
[[Category:developers]]
[[Category:Battery & Power]]

Revision as of 14:49, 6 February 2009

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Hardware_Power_Domains&oldid=194381"