[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: ACPI "hlt" mode and SMP systems?

    [ acpi list cc'ed for relevance ]

    > I once documented all of the states in a readable format. I will post it
    > once I get back from lunch...

    As promised, here is the document, slightly updated. Presented as a patch,
    for easy inlcusion into your favourite kernel tree..


    diff -Nur linux-2.4.14.orig/Documentation/power/acpi-states.txt linux-2.4.14/Documentation/power/acpi-states.txt
    --- linux-2.4.14.orig/Documentation/power/acpi-states.txt Wed Dec 31 16:00:00 1969
    +++ linux-2.4.14/Documentation/power/acpi-states.txt Tue Nov 6 15:29:24 2001
    @@ -0,0 +1,284 @@
    +Quick and Dirty Guide to ACPI States
    +Patrick Mochel
    +6 November 2001
    +1. Global States (G0 - G3)
    +2. Device Power States (D0 - D3)
    +3. System Power States (S0 - S5)
    +4. Processor Power States (C0 - C3)
    +5. Performance States (P0 - Pn)
    +6. References
    +This is the result of spending many nights and mornings deciphering the ACPI
    +spec, as well as ironing out the confusion with several people concerning the
    +various letter and number combinations.
    +This is meant to be un-bias. I personaly disagree with several of the ACPI
    +design points and requirements. This is meant to be accurate only. Please
    +email me if you find any discrepancies between this document and the spec.
    +Feel free to email me if you want an opinionated dissertation as well..
    +1. Global States (G0 - G3)
    +Global system states (G0 - G3) are logical states that are visible to
    +the user. Global states are not states that the OS can explicitly
    +transition to. They instead simply describe the current state of the
    +G0 - Working
    + - The system is normal operating mode.
    + - Devices and processors may change power and performance states.
    + - The OS is "active and responsive".
    +G1 - Sleeping
    + - The system is in an ACPI sleep state (S1 - S4).
    + - All devices are in a sleeping state.
    + - The processor is in a low power state, or is off.
    + - The operating system is suspended and not responding to any requests.
    + - All operating context has been preserved by the OS, so it can
    + resume execution from the exact point from which it left off.
    + - There is a latency involved in transitioning to the G0 state.
    +G2 - Soft Off
    + - The OS has transitioned the system to the ACPI sleep state S5.
    + - Operating context is not preserved, so the OS must completely
    + reinitialise itself to get to G0.
    + - The ACPI spec states that it is _not_ safe to disassemble the
    + system at this point.
    + - The system may still be powered on via some wake event.
    +G3 - Mechanical Off
    + - The system has been physically turned off.
    + This can happen via a mechanical switch, or removing the power cable.
    + On a laptop this is achieved by removing the battery from the system.
    + - Per spec, this is the only state in which it is safe to disassemble
    + the system.
    +2. Device Power States (D0 - D3)
    +The ACPI definition of device power states is modeled directly after
    +the PCI device power states. It defines four states (D0 - D3) which
    +the device can be in.
    +What each state means to a particular device is defined by its device
    +class (e.g. video device class, sound device class). These definitions
    +are covered in the ACPI spec, and I will not discuss them here.
    +In general, as the numerical power state increases (from D0 to D1, etc),
    +the following things happen:
    +- Power consumption decreases
    +- Device context retained by the device decreases
    +- Latency to bring the device to the D0 state increases
    +- Responsibility of the driver to have knowledge of the device state
    + increases.
    +As with the PCI definitions of low power states, the Off state (D3)
    +and the working state (D0) are supported by default by every
    +device. The other two states (D1 and D2) are optionaly supported by
    +the device class.
    +Note that support of these two states are optional at a device level,
    +as far as PCI is concerned. However, with some more recent peripheral buses
    +(e.g. PCI-X), device support for all states is mandatory.
    +Device states are defined as follows:
    +D0 - On
    + - Device is powered on and running.
    + - It is accepting I/O requests.
    +D1 -
    +D2 - Optional intermediate power states
    + - The device is not accepting any I/O requests.
    + - The device is still consuming power, though it may be less than it does
    + in the D0 state.
    + - The device may have lost some state, as it may powered down various
    + components to conserve power.
    + - The driver is responsible for preserving and restoring this state if it
    + receives a request to transition the device to the D0 state.
    +D3 - Off
    + - Device is not acception I/O requests.
    + - All device context is lost.
    + - The device must be completely reinitialised upon a transition to the D0
    + state.
    + - The device is not consuming any power.
    + (Note that the last point is not always necessarily true; the PCI Power
    + Management specs makes a distinction between D3 "Hot" -- when the device
    + is in D3, but power is still supplied to the slot -- and D3 "Cold" -- when
    + power has been removed from the controlling bus.)
    +Relation to Global System States
    + - Devices are typically in the D0 state, though they may be technically be
    + in any state (D0 - D3). They may have been placed in a low power state
    + based on a system-wide power policy or via direct user control.
    + - Devices are in a low power state (D1 - D2). The exact state is dictated by
    + both what the device supports and by what the driver is capable of
    + restoring. (Some drivers may not have enough knowledge of the device to
    + restore all of its state.)
    +G2 -
    + All devices are off.
    + Some devices may have auxillary power lines that allow the device to wake
    + the system up under certain circumstances (e.g. Wake-On-Lan).
    +G3 -
    + All devices are off.
    + No device is consuming any power.
    +3. System Sleep States (S0 - S5)
    +ACPI defines 6 states which the system can be in, S0 - S5.
    +S0 is the working state. S5 is the soft-off state. S1 - S4 are intermediate
    +sleeping states. Similar to device power states, there are tradeoffs in time
    +and power consumption for each system sleep state.
    +In general, as the numerical sleep state increases, the following are true:
    +- Power consumption decreases
    +- Context retained by system components decreases; the responsibility of the OS
    + to account for this context increases.
    +- Latency to bring the system to the S0 state increases.
    +System sleep states are defined as follows:
    +S0 - On
    + - System is running.
    +S1 - "Power On Suspend"
    + - Processor power, and hence execution context, is preserved.
    + - Devices may have been put into a low power state.
    +S2 - "Pseudo-Suspend To Ram"
    + - Processor power is removed.
    + - Devices may be placed into low power state.
    + - Memory is placed into self-refresh and retains context.
    + - Execution starts again from processor's reset vector
    + - Cache and MTRR configuration is lost during this state; the
    + firmware is responsible for restoring it to some known state.
    +S3 - "Suspend to Ram"
    + - Processor power is removed.
    + - Devices are placed into a low power state.
    + - Power may be removed from all system buses.
    + - Memory context is preserved by placing memory in Self-Refresh
    + - Execution begins from processor's reset vector
    + - Cache and MTRR configuration is lost during this state; the
    + firmware is responsible for restoring it to some known state.
    +S4 - "Suspend to Disk", aka "Hibernate"
    + - All power may be removed from the system.
    + - All device context may be lost.
    + - Context is usually written to persistant storage (e.g. disk).
    + - Execution begins at processor's reset vector; the firmware
    + will usually load the OS boot loader.
    +S5 - Soft Off
    + - Technically not a sleep state
    + - No context is retained
    + - OS is not responsible for saving context
    + - OS must completely reinitialise itself on 'resume' (power-on)
    + - Wake events may still trigger the system to resume from sleep.
    +When the system is in a sleep state, it can be woken up via a 'wake event'.
    +The type of wake events available to a user is dependent on the system
    +components and the configuration.
    +Relation to Global System States
    +G0 -
    + The system is in the S0 state.
    +G1 -
    + The system is in one of the S1 - S4 sleep states.
    +G2 -
    + The system is in the S4 sleep state.
    +G3 -
    + The system is completely off.
    +Relation to Device Power States
    +S0 -
    + Devices are typically in the D0 state, though they may be individually
    + powered down.
    +S1 -
    + Devices should be placed in a low-latency low power state (i.e. D1) if
    + they support it.
    +S2 -
    + Devices are placed in a low power state if they support it. The resume
    + latency D2 is commonly acceptable because of the savings in power.
    +S3 -
    + Devices are placed in a low power state, and power is typically removed
    + from all buses.
    + Some devices may retain power and context, based on their function in the
    + system (e.g. A memory controller may retain power so it can safely
    + resume).
    +S4 -
    +S5 -
    + All devices are powered off.
    + Some residual power may be consumed by devices that support wake events
    + and need some amount of power to generate an interrupt.
    +4. Processor States (C0 - C3)
    +ACPI defines 4 power states for processors. Each state is entered when the
    +system is running (in the G0 state), but when the processor is idle. The
    +longer the processor is idle, the deeper the sleep state it enters.
    +The four processor states are:
    +C0 - On
    + - The processor is executing instructions at this point
    +C1 - "AutoHalt"
    + - The processor executes the equivalent to the "hlt" instruction
    + on x86.
    + - All processors must support this state.
    + - Latency should be transparent to Operating System.
    +C2 - "Quick Start"
    + - Entered by reading from a system port.
    +C3 - Deep Sleep
    + - Entered by reading from a system port.
    + - Caches may not be snooped in this state.
    +The ACPI firmware tables (specifically the FADT table) tell what port to read
    +from to enter C2 and C3. The table also contains the latency involved in
    +returning from each state. (The processor states are supposed to nearly
    +transparent to the OS; so, if a latency was deemed to be too high, the OS
    +could simply choose not to enter it.)
    +5. Performance States (P0 - Pn)
    +Performance states are a mechanism for processors and devices to
    +compromise performance for lower power consumption while in the
    +fully on state (C0 or D0).
    +An example of this would be a video controller with a 3d graphics
    +engine. When placed into a lower performance state, Px, the 3d
    +graphics engine is disabled.
    +By default, all devices support and operate in the P0 state. A device or
    +processor may define a maximum of 16 performance states which the OS or an
    +application may use.
    +6. References
    +ACPI 2.0 Specification; esp. Ch 1 - 3.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:12    [W:0.038 / U:55.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site