27.10.2015 Views

Advanced Configuration and Power Interface Specification

ACPI_6.0

ACPI_6.0

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

ACPI System Management Bus <strong>Interface</strong> <strong>Specification</strong><br />

SMBus operation regions require that all field elements be declared at comm<strong>and</strong> value granularity.<br />

This means that each virtual register cannot be broken down to its individual bits within the field<br />

definition.<br />

Access to sub-portions of virtual registers can be done only outside of the field definition. This<br />

limitation is imposed both to simplify the SMBus interface <strong>and</strong> to maintain consistency with the<br />

physical model defined by the SMBus specification.<br />

SMBus protocols are assigned to field elements using the AccessAs term within the field definition.<br />

The syntax for this term (from Section 19.2.3, “ASL Root <strong>and</strong> SecondaryTerms”) is described<br />

below.<br />

AccessAs(<br />

AccessType,<br />

AccessAttribute<br />

)<br />

Where:<br />

//AccessTypeKeyword<br />

//Nothing | ByteConst | AccessAttribKeyword<br />

• AccessType must be set to BufferAcc.<br />

• AccessAttribute indicates the SMBus protocol to assign to comm<strong>and</strong> values that follow this<br />

term. See Section 13.1.2, “SMBus Protocols,” for a listing of the SMBus protocol types <strong>and</strong><br />

values.<br />

An AccessAs term must appear as the first entry in a field definition to set the initial SMBus protocol<br />

for the field elements that follow. A maximum of one SMBus protocol may be defined for each field<br />

element. Devices supporting multiple protocols for a single comm<strong>and</strong> value can be modeled by<br />

specifying multiple field elements with the same offset (comm<strong>and</strong> value), where each field element<br />

is preceded by an AccessAs term specifying an alternate protocol.<br />

For example, the register at comm<strong>and</strong> value 0x08 for a Smart Battery device (illustrated below)<br />

represents a word value specifying the battery temperature (in degrees Kelvin), while the register at<br />

comm<strong>and</strong> value 0x20 represents a variable-length (0 to 32 bytes) character string specifying the<br />

name of the company that manufactured the battery.<br />

Smart Battery Device<br />

ManufacturerAccess()<br />

RemainingCapacityAlarm()<br />

Temperature()<br />

ManufacturerName()<br />

DeviceName()<br />

Comm<strong>and</strong> Value<br />

0x00 (Word)<br />

0x01 (Word)<br />

:<br />

0x08 (Word)<br />

:<br />

0x20 (Block)<br />

0x21 (Block)<br />

:<br />

Register<br />

Byte 0 Byte 1<br />

Byte 0 Byte 1<br />

Byte 0 Byte 1<br />

Byte 0 ... Byte 31<br />

Byte 0 ... Byte 31<br />

Figure 13-75 Smart Battery Device Virtual Registers<br />

Version 6.0 667

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

Saved successfully!

Ooh no, something went wrong!