27.10.2015 Views

Advanced Configuration and Power Interface Specification

ACPI_6.0

ACPI_6.0

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Advanced</strong> <strong>Configuration</strong> <strong>and</strong> <strong>Power</strong> <strong>Interface</strong> <strong>Specification</strong><br />

initial TMR_VAL upon loading OSPM <strong>and</strong> assumes that the timer is counting. It is allowable to stop<br />

the Timer when the system transitions out of the working (G0/S0) state. The only timer reset<br />

requirement is that the timer functions while in the working state.<br />

The PM Timer’s programming model is implemented as a fixed hardware feature to increase the<br />

accuracy of reading the timer.<br />

4.8.2.2 Console Buttons<br />

ACPI defines user-initiated events to request OSPM to transition the platform between the G0<br />

working state <strong>and</strong> the G1 sleeping, G2 soft off <strong>and</strong> G3 mechanical off states. ACPI also defines a<br />

recommended mechanism to unconditionally transition the platform from a hung G0 working state<br />

to the G2 soft-off state.<br />

ACPI operating systems use power button events to determine when the user is present. As such,<br />

these ACPI events are associated with buttons in the ACPI specification.<br />

The ACPI specification supports two button models:<br />

• A single-button model that generates an event for both sleeping <strong>and</strong> entering the soft-off state.<br />

The function of the button can be configured using OSPM UI.<br />

• A dual-button model where the power button generates a soft-off transition request <strong>and</strong> a<br />

sleeping button generates a sleeping transition request. The type of button implies the function<br />

of the button.<br />

Control of these button events is either through the fixed hardware programming model or the<br />

generic hardware programming model (control method based). The fixed hardware programming<br />

model has the advantage that OSPM can access the button at any time, including when the system is<br />

crashed. In a crashed system with a fixed hardware power button, OSPM can make a “best” effort to<br />

determine whether the power button has been pressed to transition to the system to the soft-off state,<br />

because it doesn’t require the AML interpreter to access the event bits.<br />

4.8.2.2.1 <strong>Power</strong> Button<br />

The power button logic can be used in one of two models: single button or dual button. In the singlebutton<br />

model, the user button acts as both a power button for transitioning the system between the<br />

G0 <strong>and</strong> G2 states <strong>and</strong> a sleeping button for transitioning the system between the G0 <strong>and</strong> G1 states.<br />

The action of the user pressing the button is determined by software policy or user settings. In the<br />

dual-button model, there are separate buttons for sleeping <strong>and</strong> power control. Although the buttons<br />

still generate events that cause software to take an action, the function of the button is now<br />

dedicated: the sleeping button generates a sleeping request to OSPM <strong>and</strong> the power button generates<br />

a waking request.<br />

Support for a power button is indicated by a combination of the PWR_BUTTON flag <strong>and</strong> the power<br />

button device object, as shown in the following:<br />

Table 4-13 <strong>Power</strong> Button Support<br />

Indicated Support PWR_BUTTON Flag <strong>Power</strong> Button Device Object<br />

Fixed hardware power button Clear Absent<br />

Control method power button Set Present<br />

76 April, 2015 Version 6.0

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!