Advanced Configuration and Power Interface Specification Hewlett-Packard Corporation
Table 5-68 Predefined Object Names
Download 7.02 Mb.
|
- Navigate this page:
- \_GL (Global Lock Mutex)
- \_OSI (Operating System Interfaces)
- Table 5-69 Operating System Vendor Strings
- Table 5-70 Feature Group Strings
- String
- Integer
- Device Identification Objects
- Object Description
- Table 6-2 _ADR Object Address Encodings
- Integer or String
- PCI\CC_ccss”
- String
- _MLS (Multiple Language String)
- Package
Table 5-68 Predefined Object Names
This predefined object is a Mutex object that behaves like a Mutex as defined in section 18.5.79, “Mutex (Declare Synchronization/Mutex Object),” with the added behavior that acquiring this Mutex also acquires the shared environment Global Lock defined in section 5.2.10.1, “Global Lock.” This allows Control Methods to explicitly synchronize with the Global Lock if necessary.
This object provides the platform with the ability to query OSPM to determine the set of ACPI related interfaces, behaviors, or features that the operating system supports. The _OSI method has one argument and one return value. The argument is an OS vendor defined string representing a set of OS interfaces and behaviors or an ACPI defined string representing an operating system and an ACPI feature group of the form, “OSVendorString-FeatureGroupString”. Arguments: (1) Arg0 – A String containing the OS interface / behavior compatibility string or the Feature Group string, as defined in Table 5-70, or the “OS Vendor String Prefix – OS Vendor Specific String”. OS Vendor String Prefixes are defined in Table 5-69 Return Value: An Integer containing a Boolean that indicates whether the requested feature is supported: 0x0 – The interface, behavior, or feature is not supported 0xFFFFFFFF – The interface, behavior, or feature is supported OSPM may indicate support for multiple OS interface / behavior strings if the operating system supports the behaviors. For example, a newer version of an operating system may indicate support for strings from all or some of the prior versions of that operating system. _OSI provides the platform with the ability to support new operating system versions and their associated features when they become available. OSPM can choose to expose new functionality based on the _OSI argument string. That is, OSPM can use the strings passed into _OSI to ensure compatibility between older platforms and newer operating systems by maintaining known compatible behavior for a platform. As such, it is recommended that _OSI be evaluated by the \_SB.INI control method so that platform compatible behavior or features are available early in operating system initialization. Since feature group functionality may be dependent on OSPM implementation, it may be required that OS vendor-defined strings be checked before feature group strings. Platform developers should consult OS vendor specific information for OS vendor defined strings representing a set of OS interfaces and behaviors. ACPI defined strings representing an operating system and an ACPI feature group are listed in the following tables. Table 5-69 Operating System Vendor Strings
Strings'>Table 5-70 Feature Group Strings
_OSI Example ASL using OS vendor defined string: Scope (_SB) //Scope { Name (TOOS, 0) // Global variable for type of OS. // This methods sets the "TOOS" variable depending on the type of OS // installed on the system. // TOOS = 1 // Windows 98 & SE // TOOS = 2 // Windows Me. // TOOS = 3 // Windows 2000 OS or above version. // TOOS = 4 // Windows XP OS or above version. Method (_INI) { If (CondRefOf (_OSI,Local0)) { If (\_OSI ("Windows 2001")) { Store(4, TOOS) } } Else { Store (\_OS, local0) If (LEqual (local0, "Microsoft Windows NT")) { Store (3, TOOS) } ElseIf (LEqual (Local0, "Microsoft Windows")) { Store (1, TOOS) } ElseIf (LEqual (Local0, "Microsoft WindowsME:Millennium Edition")) { Store (2, TOOS) } } } } _OSI Example ASL using an ACPI defined string: Scope (_SB) { Method (_INI) { If (CondRefOf (_OSI,Local0)) { If (\_OSI ("Module Device")) { //Expose PCI Root Bridge under Module Device LoadTable(“OEM1", “OEMID", “Table1",,,)} Else { // Expose PCI Root Bridge under \_SB – OS does not support Module Device LoadTable(“OEM1", “OEMID", “Table2",,,)} } Else { // Default Behavior LoadTable(“OEM1", “OEMID", “Table2",,,)} } //_INI Method } //_SB scope DefinitionBlock (“MD1SSDT.aml",“OEM1",0x02, “OEMID", "Table1", 0) { Scope(\_SB) { Device (\_SB.NOD0) { Name (_HID, "ACPI0004") // Module device Name (_UID, 0) Name (_PRS, ResourceTemplate() {...}) Method (_SRS, 1) {...} Method (_CRS, 0) {...} Device (PCI0) { // PCI Root Bridge Name (_HID, EISAID("PNP0A03")) Name (_UID, 0) Name (_BBN, 0x00) Name (_PRS, ResourceTemplate () {...}) } // end of PCI Root Bridge } // end of Module device } // end of \_SB Scope } // end of Definition Block DefinitionBlock (“MD1SSDT.aml",“OEM1",0x02, “OEMID", "Table2", 0) { Scope(\_SB) { Device (PCI0) { // PCI Root Bridge Name (_HID, EISAID("PNP0A03")) Name (_UID, 0) Name (_BBN, 0x00) Name (_PRS, ResourceTemplate () {...}) } // end of PCI Root Bridge } // end of \_SB Scope } // end of Definition Block
This predefined object evaluates to a string that identifies the operating system. In robust OSPM implementations, \_OS evaluates differently for each OS release. This may allow AML code to accommodate differences in OSPM implementations. This value does not change with different revisions of the AML interpreter. Arguments: None
Return Value: A String containing the operating system name
This predefined object evaluates to the revision of the ACPI Specification that the specified \_OS implements as a DWORD. Larger values are newer revisions of the ACPI specification. Arguments: None
Return Value: An Integer containing the revision of the currently executing ACPI implementation
The \_PIC optional method is used to report to the BIOS the current interrupt model used by the OS. This control method returns nothing. The argument passed into the method signifies the interrupt model OSPM has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this method is optional for OSPM. If the method is never called, the BIOS must assume PIC mode. It is important that the BIOS save the value passed in by OSPM for later use during wake operations. Arguments: (1) Arg0 – An Integer containing a code for the current interrupt model: 0 – PIC mode 1 – APIC mode 2 – SAPIC mode Other values – Reserved Return Value: None
This section specifies the objects OSPM uses to configure devices. There are three types of configuration objects:
This section also defines the ACPI device–resource descriptor formats. Device–resource descriptors are used as parameters by some of the device configuration objects.
Device identification objects associate each platform device with a Plug and Play device ID for each device. All the device identification objects are listed Table 6-1: Table 6-1 Device Identification Objects
For any device that is not on an enumerable type of bus (for example, an ISA bus), OSPM enumerates the devices’ Plug and Play ID(s) and the ACPI BIOS must supply an _HID object (plus an optional _CID object) for each device to enable OSPM to do that. For devices on an enumerable type of bus, such as a PCI bus, the ACPI system must identify which device on the enumerable bus is identified by a particular Plug and Play ID; the ACPI BIOS must supply an _ADR object for each device to enable this. A device object must contain either an _HID object or an _ADR object, but can contain both. If any of these objects are implemented as control methods, these methods may depend on operation regions. Since the control methods may be evaluated before an operation region provider becomes available, the control method must be structured to execute in the absence of the operation region provider. (_REG methods notify the BIOS of the presence of operation region providers.) When a control method cannot determine the current state of the hardware due to a lack of operation region provider, it is recommended that the control method should return the condition that was true at the time that control passed from the BIOS to the OS. (The control method should return a default, boot value).
This object is used to supply OSPM with the address of a device on its parent bus. An _ADR object must be used when specifying the address of any device on a bus that has a standard enumeration algorithm (see 3.7, “Configuration and Plug and Play”, for the situations when these devices do appear in the ACPI namespace). Arguments: None
Return Value: An Integer containing the address of the device An _ADR object can be used to provide capabilities to the specified address even if a device is not present. This allows the system to provide capabilities to a slot on the parent bus. OSPM infers the parent bus from the location of the _ADR object’s device package in the ACPI namespace. For more information about the positioning of device packages in the ACPI namespace, see section 18.5.28, “Device (Declare Bus/Device Package)” _ADR object information must be static and can be defined for the following bus types listed in Table 6-2.
This optional object is used to supply OSPM with a device’s Plug and Play-Compatible Device ID. Use _CID objects when a device has no other defined hardware standard method to report its compatible IDs. Arguments: None
Return Value: An Integer or String containing a single CID or a Package containing a list of CIDs A _CID object evaluates to either:
Each Compatible Device ID must be either:
“PCI\CC_ccss” “PCI\CC_ccsspp” “PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr” “PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss” “PCI\VEN_vvvv&DEV_dddd&REV_rr” “PCI\VEN_vvvv&DEV_dddd”
cc – hexadecimal representation of the Class Code byte ss – hexadecimal representation of the Subclass Code byte pp – hexadecimal representation of the Programming Interface byte vvvv – hexadecimal representation of the Vendor ID dddd – hexadecimal representation of the Device ID ssssssss – hexadecimal representation of the Subsystem ID rr – hexadecimal representation of the Revision byte A compatible ID retrieved from a _CID object is only meaningful if it is a non-NULL value. Example ASL: Device (XYZ) { Name (_HID, EISAID ("PNP0303")) // PC Keyboard Controller Name (_CID, EISAID ("PNP030B")) }
This object is used to associate a logical name (for example, COM1) with a device. This name can be used by applications to connect to the device. Arguments: None
Return Value: A String containing the DOS device name
This object is used to supply OSPM with the device’s Plug and Play hardware ID.8 When describing a platform, use of any _HID objects is optional. However, a _HID object must be used to describe any device that will be enumerated by OSPM. OSPM only enumerates a device when no bus enumerator can detect the device ID. For example, devices on an ISA bus are enumerated by OSPM. Use the _ADR object to describe devices enumerated by bus enumerators other than OSPM. Arguments: None
Return Value: An Integer or String containing the HID A _HID object evaluates to either a numeric 32-bit compressed EISA type ID or a string. If a string, the format must be an alphanumeric PNP or ACPI ID with no asterisk or other leading characters. A valid PNP ID must be of the form “AAA####” where A is an uppercase letter and # is a hex digit. A valid ACPI ID must be of the form “ACPI####” where # is a hex digit. Example ASL: Name (_HID, EISAID ("PNP0C0C")) // Control-Method Power Button Name (_HID, EISAID ("INT0800")) // Firmware Hub Name (_HID, "ACPI0003") // AC adapter device
The _MLS object provides OSPM a human readable description of a device in multiple languages. This information may be provided to the end user when the OSPM is unable to get any other information about this device. Although this functionality is also provided by the _STR object, _MLS expands that functionality and provides vendors with the capability to provide multiple strings in multiple languages. The _MLS object evaluates to a package of packages. Each sub-package consists of a Language identifier and corresponding unicode string for a given locale. Specifying a language identifier allows OSPM to easily determine if support for displaying the Unicode string is available. OSPM can use this information to determine whether or not to display the device string, or which string is appropriate for a user’s preferred locale. It is assumed that OSPM will always support the primary English locale to accommodate English embedded in a non-English string, such as a brand name. If OSPM doesn’t support the specific sub-language ID it may choose to use the primary language ID for displaying device text.
None
Return Value: A variable-length Package containing a list of language descriptor Packages as described below. Return Value Information Package { LanguageDescriptor[0] // Package LanguageDescriptor[n] // Package } Each Language Descriptor sub-Package contains the elements described below: Package { LanguageId // String UnicodeDescription // String }
Directory: DOWNLOADS DOWNLOADS -> Northern England’s set-jetting locations DOWNLOADS -> Dynatest 3031 lwd light Weight Deflectometer DOWNLOADS -> Forth coming competitive exams DOWNLOADS -> Brush High School Morning Announcements Friday, September 05, 2014 all school DOWNLOADS -> Year 9 The Arts — Music DOWNLOADS -> Years 7 and 8 standard elaborations — Australian Curriculum: Music draft DOWNLOADS -> Chris Young sets 2016 “I’m Comin’ Over” Tour headlining dates DOWNLOADS -> Slavery and Abolition: the Plymouth Connection Introduction DOWNLOADS -> Summer Assignment Download 7.02 Mb. Share with your friends:
|