When will the equivalence of "hlt" (in APM) work in ACPI SMP systems? Or
does it already? I have a hard time decoding all the ACPI symbols, such as
C1 C2 S0 S1 S2 S3 and so on...
_____________________________________________________
| Martin Eriksson <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
On Tue, 6 Nov 2001, Martin Eriksson wrote:
> When will the equivalence of "hlt" (in APM) work in ACPI SMP systems? Or
> does it already? I have a hard time decoding all the ACPI symbols, such as
> C1 C2 S0 S1 S2 S3 and so on...
"hlt" is equivalent to ACPI processor power state C1,
When ACPI is loaded, it replaces the idle function with its own
(drivers/acpi/ospm/processor/prpower.c::pr_power_idle() ), which places
the processors in lower power states gradually.
I once documented all of the states in a readable format. I will post it
once I get back from lunch...
-pat
> From: Martin Eriksson [mailto:[email protected]]
> When will the equivalence of "hlt" (in APM) work in ACPI SMP
> systems? Or
> does it already? I have a hard time decoding all the ACPI
> symbols, such as
> C1 C2 S0 S1 S2 S3 and so on...
The hlt instruction is an x86 thing, not an APM or ACPI thing. However, the
ACPI C1 state corresponds to using hlt. It works on ACPI SMP systems right
now.
Regards -- Andy
[ 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..
-pat
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
+<[email protected]>
+
+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
+
+0.
+~~
+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
+system.
+
+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
+
+G0
+ - 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.
+G1
+ - 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.
+<http://acpi.info>
+
Hi!
I have few comments...
> +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.
If S2 and S3 are same, you should use exactly same text. It seems to say
exactly same thing in slightly different words.
> +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.
...
> +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.
~~
this should be S5, no?
> +6. References
> +~~~~~~~~~~~~~
> +
> +ACPI 2.0 Specification; esp. Ch 1 - 3.
> +<http://acpi.info>
~~~~~~~~~~~~~~~~
This url does not seem too real.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Thu, Nov 08, 2001 at 02:34:34PM +0000, Pavel Machek wrote:
> > +ACPI 2.0 Specification; esp. Ch 1 - 3.
> > +<http://acpi.info>
> ~~~~~~~~~~~~~~~~
> This url does not seem too real.
it in fact _is_ a working URL..
--
Grobbebol's Home | Don't give in to spammers. -o)
http://www.xs4all.nl/~bengel | Use your real e-mail address /\
Linux 2.4.14 (noapic) SMP 466MHz/768 MB | on Usenet. _\_v
Hi Pavel.
>> +<http://acpi.info>
> ~~~~~~~~~~~~~~~~
> This url does not seem too real.
I've just checked, and it's a valid one. The new .info domains came into
action 1 Nov 2001 if I remember right, and that one's exactly what it
claims to be...
Best wishes from Riley.