pci 1 irq assignment nedir

How to Configure Interrupt Request (IRQ) Priorities in Windows

A real improvement or a placebo tweak?

Most components directly attached to your motherboard—including PCI slots, IDE controllers, serial ports, the keyboard port, and even your motherboard’s CMOS—have individual interrupt requests (IRQs) assigned to them.

An interrupt request line, or IRQ, is a numbered hardware line over which a device can interrupt the normal flow of data to the processor, allowing the device to function.

Windows Vista and 7 lets you prioritize one or more IRQs (which translate to one or more hardware devices), potentially improving the performance of those devices.  Below are basic registry editing tips that you can use to set IRQ priorities.

1. Start by opening the System Information utility (msinfo32.exe), and navigating to System Summary\Hardware Resources\IRQs to view the IRQs in use on your system, and the devices using them.

Take note of IRQ13 (Numeric Data processor) that we will use in this example:

Some users have gotten good results prioritizing IRQ 8 (for the system CMOS) and the IRQ corresponding to the video card, but the feedback is unconfirmed. Do you think it is a placebo tweak? Post your comments!

Founder of Help Desk Geek and managing editor. He began blogging in 2007 and quit his job in 2010 to blog full-time. He has over 15 years of industry experience in IT and holds several technical certifications. Read Aseem's Full Bio

Read More Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *

• Docs »
• 6. Device Configuration

6. Device Configuration ¶

This section specifies the objects OSPM uses to configure devices. There are three types of configuration objects:

Device identification objects associate platform devices with Plug and Play IDs. Device configuration objects declare and configure hardware resources and characteristics for devices enumerated via ACPI. Device insertion and removal objects provide mechanisms for handling dynamic insertion and removal of devices.

There are two types of Device objects:

A Full Device Descriptor, which contains the complete description of a devices that cannot be discovered through any other standard Bus enumeration mechanism. This type of Device object is enumerated by the ACPI subsystem (OSPM), and contains a Hardware ID object (_HID). An Agumented Device Descriptor, which contains additional device information that is not provided from the Device itself, yet is needed by the Device or Bus driver in order to properly configure and use the device. This type of device is enumerated by a bus-specific enumeration mechanism, and OSPM uses the Address (_ADR) to match the ACPI Device object in the Namespace to the device discovered through bus enumeration.

This section also defines the ACPI device-resource descriptor formats. Device-resource descriptors are used as parameters by some of the device configuration objects.

6.1. Device Identification 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 in the table below:

For any device that is on a non-enumerable type of bus (for example, an ISA bus), OSPM enumerates the devices’ identifier(s) and the ACPI system firmware must supply an _HID object (plus one or more optional objects such as _CID, _CLS, _HRV, _SUB) 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 address; the ACPI system firmware 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 must not 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 platform runtime firmware 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 platform boot firmware to the OS. (The control method should return a default, boot value).

6.1.1. _ADR (Address) ¶

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 Configuration and “Plug and Play” , for the situations when these devices do appear in the ACPI namespace). The _ADR object is valid only within an Augmented Device Descriptor.

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 and segment 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 Device (Declare Device Package) _ADR object information must be static and can be defined for the following bus types listed in ADR Object Address Encodings .

6.1.2. _CID (Compatible ID) ¶

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. The _CID object is valid only within a Full Device Descriptor. An _HID object must also be present.

An Integer or String containing a single CID or a Package containing a list of CIDs A _CID object evaluates to either: A single Compatible Device ID A package of Compatible Device IDs for the device – in the order of preference, highest preference first.

Each Compatible Device ID must be either:

A valid HID value (a 32-bit compressed EISA type ID or a string such as “ACPI0004”). A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. The format of a PCI ID string is one of the following: "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" Where: 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 :

6.1.3. _CLS (Class Code) ¶

This object is used to supply OSPM with the PCI-defined base-class, sub-class and programming interface for a device. This object is optional. However, it may be useful for loading generic drivers on hardware that is compatible with PCI -defined device classes, but that is not implemented on the PCI bus (and is therefore enumerated by ACPI.)

A Package containing the PCI -defined class information as a list of Integers : Package(3) {<base-class code>, <sub-class code>, <Programming Interface code>}

A list of available class codes and programming interface codes is provided by the PCI SIG. See “PCI Code and ID Assignment Specification”, available from “Links to ACPI-Related Documents” ( http://uefi.org/acpi ) under the heading “PCI Code and ID Assignment Specification

Example ASL:

6.1.4. _DDN (DOS Device Name) ¶

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.

A String containing the DOS device name

6.1.5. _HID (Hardware ID) ¶

This object is used to supply OSPM with the device’s PNP ID or ACPI ID.

PNP ID and ACPI ID Registry is at http://www.uefi.org/PNP_ACPI_Registry .

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. The _HID object is valid only within a Full Device Descriptor.

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 “NNNN####” where N is an uppercase letter or a digit (‘0’-‘9’) and # is a hex digit. This specification reserves the string “ACPI” for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.

6.1.6. _HRV (Hardware Revision) ¶

This object is used to supply OSPM with the device’s hardware revision. The use of _HRV is optional.

An Integer (DWORD) containing the hardware revision number

6.1.7. _MLS (Multiple Language String) ¶

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.

A variable-length Package containing a list of language descriptor Packages as described below.

Return Value Information :

Each Language Descriptor sub-Package contains the elements described below:

LanguageId is a string identifying the language. This string follows the format specified in the Internet RFC 3066 document (Tags for the Identification of Languages). In addition to supporting the existing strings in RFC 3066, the table below lists aliases that are also supported.

UnicodeDescription is a Buffer containing a Unicode (UTF-16) string. This string contains the language-specific description of the device corresponding to the LanguageID. The Unicode() ASL macro can be used to create this Buffer.

6.1.8. _PLD (Physical Location of Device) ¶

This optional object is a method that conveys to OSPM a general description of the physical location of a device’s external connection point. The _PLD may be child object for any ACPI Namespace object the system wants to describe. This information can be used by system software to describe to the user which specific connector or device input mechanism may be used for a given task or may need user intervention for correct operation. The _PLD should only be evaluated when its parent device is present as indicated by the device’s presence mechanism (i.e. _STA or other)

An externally exposed device connection point can reside on any surface of a system’s housing. The respective surfaces of a system’s housing are identified by the “Panel” field (described below). The _PLD method returns data to describe the location of where the device’s connection point resides and a Shape (described below) that may be rendered at that position. One physical device may have several connection points. A _PLD describes the offset and rotation of a single device connection point from an “origin” that resides in the lower left hand corner of its Panel.

All Panel references (Top, Bottom, Right, Left, etc.) are interpreted as though the user is facing the front of the system. For handheld mobile devices, the front panel is the one holding the display screen, and its origin is in the lower-left corner when the display is viewed in the Portrait orientation. For example, the Right Panel is the right side of the system as viewed from the front.

All “origin” references for a Panel are interpreted as its lower left corner when the user is facing the respective Panel. The Top Panel shall be viewed with the system is viewed resting on its Front Panel, and the Bottom Panel shall be viewed with the system resting on its Back Panel. All other Panels shall be viewed with the system resting on its Bottom Panel. See System Panel and Panel Origin Positions for more information.

Fig. 6.1 System Panel and Panel Origin Positions ¶

The data bits also assume that if the system is capable of opening up like a laptop that the device may exist on the base of the laptop system or on the lid. In the case of the latter, the “Lid” bit (described below) should be set indicating the device connection point is on the lid. If the device is on the lid, the description describes the device’s connection point location when the system is opened with the lid up. If the device connection point is not on the lid, then the description describes the device’s connection point location when the system with the lid closed.

Fig. 6.2 Laptop Panel and Panel Origin Positions ¶

To render a view of a system Panel, all _PLDs that define the same Panel and Lid values are collected. The _PLDs are then sorted by the value of their Order field and the view of the panel is rendered by drawing the shapes of each connection point (in their correct Shape, Color, Horizontal Offset, Vertical Offset, Width, Height, and Orientation) starting with all Order = 0 _PLDs first. Refer to PLD Back Panel Rendering for an example.

The location of a device connection point may change as a result of the system connecting or disconnecting to a docking station or a port replicator. As such, Notify event of type 0x09 will cause OSPM to re-evaluate the _PLD object residing under the particular device notified. If a platform is unable to detect the change of connecting or disconnecting to a docking station or port replicator, a _PLD object should not be used to describe the device connection points that will change location after such an event.

A variable-length Package containing a list of Buffers

This method returns a package containing a single or multiple buffer entries. At least one buffer entry must be returned using the bit definitions below.

All additional buffer entries returned may contain OEM-specific data, but must begin in a {GUID, data} pair. These additional data may provide complimentary physical location information specific to certain systems or class of machines.

Fig. 6.3 Default Shape Definitions ¶

Buffers 1–N Return Value (Optional) :

Buffer 1 Bit [127:0] - GUID 1

Buffer 2 Bit [127:0] - Data 1

Buffer 3 Bit [127:0] - GUID 2

Buffer 4 Bit [127:0] - Data 2

PLD Back Panel Rendering provides an example of a rendering of the external device connection points that may be conveyed to the user by _PLD information. Note that three _PLDs (System Back Panel, Power Supply, and Motherboard (MB) Connector Area) that are associated with the System Bus tree (_SB) object. Their Reference flag is set indicating that are used to provide the user with visual queues for identifying the relative locations of the other device connection points.

The connection points (C1 through C16) are defined by _PLD objects found in the System bus tree.

The following connection points all have their Panel and Lid fields set to Back and 0, respectively. And the Reference flag of the System Back Panel, Power Supply, and MB Connector Area connection points are set to 1. in this example are used to render PLD Back Panel Rendering :

Note that the origin is in the lower left hand corner of the Back Panel, where positive Horizontal and Vertical Offset values are to the right and up, respectively.

Fig. 6.4 PLD Back Panel Rendering ¶

6.1.9. _SUB (Subsystem ID) ¶

This object is used to supply OSPM with the device’s Subsystem ID. The use of _SUB is optional.

A String containing the SUB A _SUB object evaluates to a string and the format must be a valid PNP or ACPI ID with no asterisk or other leading characters. See the definition of _HID ( _HID (Hardware ID) ) for the definition of PNP and ACPI ID strings.

6.1.10. _STR (String) ¶

The _STR object evaluates to a Unicode string that describes the device or thermal zone. It may be used by an OS to provide information to an end user. This information is particularly valuable when no other information is available.

A Buffer containing a Unicode string that describes the device

Then, when all else fails, an OS can use the info included in the _STR object to describe the hardware to the user.

6.1.11. _SUN (Slot User Number) ¶

_SUN is an object that evaluates to the slot-unique ID number for a slot. _SUN is used by OSPM UI to identify slots for the user. For example, this can be used for battery slots, PCI slots, PCMCIA slots, or swappable bay slots to inform the user of what devices are in each slot. _SUN evaluates to an integer that is the number to be used in the user interface.

An Integer containing the slot’s unique ID The _SUN value is required to be unique among the slots of the same type. It is also recommended that this number match the slot number printed on the physical slot whenever possible.

6.1.12. _UID (Unique ID) ¶

This object provides OSPM with a logical device ID that does not change across reboots. This object is optional, but is required when the device has no other way to report a persistent unique device ID. The _UID must be unique across all devices with either a common _HID or _CID. This is because a device needs to be uniquely identified to the OSPM, which may match on either a _HID or a _CID to identify the device. The uniqueness match must be true regardless of whether the OSPM uses the _HID or the _CID. OSPM typically uses the unique device ID to ensure that the device-specific information, such as network protocol binding information, is remembered for the device even if its relative location changes. For most integrated devices, this object contains a unique identifier.

In general, a _UID object evaluates to either a numeric value or a string. However, when defining an object with an _HID of ACPI0007 (processor definition objects), the _UID object must return an integer. This integer is used as an identifier in the MADT, PPTT and other tables to connect non-enumerable devices to a processor object. When a string is used in these cases, there is no mechanism for connecting these devices.

An Integer or String containing the Unique ID

6.2. Device Configuration Objects ¶

This section describes objects that provide OSPM with device specific information and allow OSPM to configure device operation and resource utilization.

OSPM uses device configuration objects to configure hardware resources for devices enumerated via ACPI. Device configuration objects provide information about current and possible resource requirements, the relationship between shared resources, and methods for configuring hardware resources.

these objects must only be provided for devices that cannot be configured by any other hardware standard such as PCI, PCMCIA, and soon.

When OSPM enumerates a device, it calls _PRS to determine the resource requirements of the device. It may also call _CRS to find the current resource settings for the device. Using this information, the Plug and Play system determines what resources the device should consume and sets those resources by calling the device’s _SRS control method.

In ACPI, devices can consume resources (for example, legacy keyboards), provide resources (for example, a proprietary PCI bridge), or do both. Unless otherwise specified, resources for a device are assumed to be taken from the nearest matching resource above the device in the device hierarchy.

Some resources, however, may be shared amongst several devices. To describe this, devices that share a resource (resource consumers) must use the extended resource descriptors (0x7-0xA) described in Large Resource Data Type . These descriptors point to a single device object (resource producer) that claims the shared resource in its _PRS. This allows OSPM to clearly understand the resource dependencies in the system and move all related devices together if it needs to change resources. Furthermore, it allows OSPM to allocate resources only to resource producers when devices that consume that resource appear.

The device configuration objects are listed in the table below.

6.2.1. _CDM (Clock Domain) ¶

This optional object conveys the processor clock domain to which a processor belongs. A processor clock domain is a unique identifier representing the hardware clock source providing the input clock for a given set of processors. This clock source drives software accessible internal counters, such as the Time Stamp Counter, in each processor. Processor counters in the same clock domain are driven by the same hardware clock source. In multi-processor platforms that utilize multiple clock domains, such counters may exhibit drift when compared against processor counters on different clock domains.

The _CDM object evaluates to an integer that identifies the device as belonging to a specific clock domain. OSPM assumes that two devices in the same clock domain are connected to the same hardware clock.

An Integer (DWORD) containing a clock domain identifier.

In the case the platform does not convey any clock domain information to OSPM via the SRAT or the _CDM object, OSPM assumes all logical processors to be on a common clock domain. If the platform defines _CDM object under a logical processor then it must define _CDM objects under all logical processors whose clock domain information is not provided via the SRAT.

6.2.2. _CRS (Current Resource Settings) ¶

This required object evaluates to a byte stream that describes the system resources currently allocated to a device. Additionally, a bus device must supply the resources that it decodes and can assign to its children devices. If a device is disabled, then _CRS returns a valid resource template for the device, but the actual resource assignments in the return byte stream are ignored. If the device is disabled when _CRS is called, it must remain disabled.

The format of the data contained in a _CRS object follows the formats defined in Resource Data Types for ACPI , which is a compatible extension of the Plug and Play BIOS Specification (see reference below). The resource data is provided as a series of data structures, with each of the resource data structures having a unique tag or identifier. The resource descriptor data structures specify the standard PC system resources, such as memory address ranges, I/O ports, interrupts, and DMA channels.

Plug and Play BIOS Specification Version 1.0A, May 5, 1994, Compaq Computer Corp., Intel Corp., Phoenix Technologies Ltd.

A Buffer containing a resource descriptor byte stream

6.2.3. _DIS (Disable) ¶

This control method disables a device. When the device is disabled, it must not be decoding any hardware resources. Prior to running this control method, OSPM will have already put the device in the D3 state.

When a device is disabled via the _DIS, the _STA control method for this device must return with the Disabled bit set.

6.2.4. _DMA (Direct Memory Access) ¶

This optional object returns a byte stream in the same format as a _CRS object. _DMA is only defined under devices that represent buses. It specifies the ranges the bus controller (bridge) decodes on the child-side of its interface. (This is analogous to the _CRS object, which describes the resources that the bus controller decodes on the parent-side of its interface.) Any ranges described in the resources of a _DMA object can be used by child devices for DMA or bus master transactions.

The _DMA object is only valid if a _CRS object is also defined. OSPM must re-evaluate the _DMA object after an _SRS object has been executed because the _DMA ranges resources may change depending on how the bridge has been configured.

If the _DMA object is not present for a bus device, the OS assumes that any address placed on a bus by a child device will be decoded either by a device on the bus or by the bus itself, (in other words, all address ranges can be used for DMA).

For example, if a platform implements a PCI bus that cannot access all of physical memory, it has a _DMA object under that PCI bus that describes the ranges of physical memory that can be accessed by devices on that bus.

A _DMA object is not meant to describe any “map register” hardware that is set up for each DMA transaction. It is meant only to describe the DMA properties of a bus that cannot be changed without reevaluating the _SRS method.

_DMA Example ASL:

6.2.5. _DSD (Device Specific Data) ¶

This optional object is used to provide device drivers (via OSPM) with additional device properties and information. _DSD returns a variable-length package containing a list of Device Data Descriptor structures each consisting of a UUID (see Universally Unique Identifiers (UUIDs) ) and a package (Data Structure). The UUID is all that is needed to define the Data Structure. The UUID itself may place a restriction based on _HID or the optional _CID, _CLS, _HRV, _SUB objects, or _HID and one of those optional objects. However, it also may not place such a restriction.

New UUIDs may be created by OEMs and IHVs or other interface or device governing bodies (e.g. the PCI SIG or the UEFI Forum), as long as the UUID is different from other published UUIDs.

The list of well-known UUIDs allocated for _DSD and the definition of data formats associated with them is available in an auxiliary document hosted on the UEFI Forum: http://www.uefi.org/acpi .

A variable-length Package containing a list of Device Data Descriptor structures as described below.

Return Value Information:

Each Device Data Descriptor structure consists of two elements, as follows:

UUID uniquely determines the format of Data Structure.

Data Structure is a set of device specific data items the format of which is uniquely determined by the UUID and the meaning of which is uniquely determined by the UUID possibly in combination with a PNP or ACPI device ID.

Multiple Device Data Descriptor structures with the same UUID are not permitted.

_DSD must return the same data each time it is evaluated. Firmware should not expect it to be evaluated every time (in case it is implemented as a method).

The UUID used in the following examples is assumed to define the data format for Data Structure as a list of packages of length 2 (Properties) whose first element (Key) must be a String and the second element is a Value associated with that key. The set of valid Keys and the format and interpretation of the Values associated with them is then dependent on the PNP or ACPI device ID of the device.

6.2.6. _FIX (Fixed Register Resource Provider) ¶

This optional object is used to provide a correlation between the fixed-hardware register blocks defined in the FADT and the devices in the ACPI namespace that implement these fixed-hardware registers. This object evaluates to a package of Plug and Play-compatible IDs (32-bit compressed EISA type IDs) that correlate to the fixed-hardware register blocks defined in the FADT. The device under which _FIX appears plays a role in the implementation of the fixed-hardware (for example, implements the hardware or decodes the hardware’s address). _FIX conveys to OSPM whether a given device can be disabled, powered off, or should be treated specially by conveying its role in the implementation of the ACPI fixed-hardware register interfaces. This object takes no arguments.

The _CRS object describes a device’s resources. That _CRS object may contain a superset of the resources in the FADT, as the device may actually decode resources beyond what the FADT requires. Furthermore, in a machine that performs translation of resources within I/O bridges, the processor-relative resources in the FADT may not be the same as the bus-relative resources in the _CRS.

A variable-length Package containing a list of Integers , each containing a PNP ID

Each of fields in the FADT has its own corresponding Plug and Play ID, as shown below:

Example ASL for _FIX usage:

6.2.7. _GSB (Global System Interrupt Base) ¶

_GSB is an optional object that evaluates to an integer that corresponds to the Global System Interrupt Base for the corresponding I/O APIC device. The I/O APIC device may either be bus enumerated (e.g. as a PCI device) or enumerated in the namespace as described in I/O APIC Device . Any I/O APIC device that either supports hot-plug or is not described in the MADT must contain a _GSB object.

If the I/O APIC device also contains a _MAT object, OSPM evaluates the _GSB object first before evaluating the _MAT object. By providing the Global System Interrupt Base of the I/O APIC, this object enables OSPM to process only the _MAT entries that correspond to the I/O APIC device. See _MAT (Multiple APIC Table Entry) . Since _MAT is allowed to potentially return all the MADT entries for the entire platform, _GSB is needed in the I/O APIC device scope to enable OSPM to identify the entries that correspond to that device.

If an I/O APIC device is activated by a device-specific driver, the physical address used to access the I/O APIC will be exposed by the driver and cannot be determined from the _MAT object. In this case, OSPM cannot use the _MAT object to determine the Global System Interrupt Base corresponding to the I/O APIC device and hence requires the _GSB object.

The Global System Interrupt Base is a 64-bit value representing the corresponding I/OAPIC device as defined in Global System Interrupts .

None Return Value: An Integer containing the interrupt base

Example ASL for _GSB usage for a non-PCI based I/O APIC Device:

Example ASL for _GSB usage for a PCI-based I/O APIC Device:

6.2.8. _HPP (Hot Plug Parameters) ¶

This optional object evaluates to a package containing the cache-line size, latency timer, SERR enable, and PERR enable values to be used when configuring a PCI device inserted into a hot-plug slot or for performing configuration of a PCI devices not configured by the platform boot firmware at system boot. The object is placed under a PCI bus where this behavior is desired, such as a bus with hot-plug slots. _HPP provided settings apply to all child buses, until another _HPP object is encountered.

A Package containing the Integer hot-plug parameters

Example: Using _HPP

OSPM will configure a PCI device on a card hot-plugged into slot 1 or slot 2, with a cache line size of 32 (Notice this field is in DWORDs), latency timer of 64, enable SERR, but leave PERR alone.

6.2.9. _HPX (Hot Plug Parameter Extensions) ¶

This optional object provides platform-specific information to the OSPM PCI driver component responsible for configuring PCI, PCI-X, or PCI Express Functions. The information conveyed applies to the entire hierarchy downward from the scope containing the _HPX object. If another _HPX object is encountered downstream, the settings conveyed by the lower-level object apply to that scope downward.

OSPM uses the information returned by _HPX to determine how to configure PCI Functions that are hot-plugged into the system, to configure Functions not configured by the platform firmware during initial system boot, and to configure Functions any time they lose configuration space settings (e.g. OSPM issues a Secondary Bus Reset/Function Level Reset or Downstream Port Containment is triggered). The _HPX object is placed within the scope of a PCI-compatible bus where this behavior is desired, such as a bus with hot-plug slots. It returns a single package that contains one or more sub-packages, each containing a single Setting Record. Each such Setting Record contains a Setting Type (INTEGER), a Revision number (INTEGER) and type/revision specific contents.

The format of data returned by the _HPX object is extensible. The Setting Type and Revision number determine the format of the Setting Record. OSPM ignores Setting Records of types that it does not understand. A Setting Record with higher Revision number supersedes that with lower revision number, however, the _HPX method can return both together, OSPM shall use the one with highest revision number that it understands. Type 3 records may have multiple records with the same revision or different revision (refer to the Revision field in PCI Express Descriptor Setting Record Content . Out of all the Type 3 records, the OSPM shall determine the highest revision number that it understands and use all Type 3 records with that revision.

_HPX may return multiple types or Record Settings (each setting in a single sub-package.) OSPM is responsible for detecting the type of Function and for applying the appropriate settings. OSPM is also responsible for detecting the device / port type of the PCI Express Function and applying the appropriate settings provided. For example, the Secondary Uncorrectable Error Severity and Secondary Uncorrectable Error Mask settings of Type 2 record are only applicable to PCI Express to PCI-X/PCI Bridge whose device / port type is 1000b. Similarly, AER settings are only applicable to hot plug PCI Express devices that support the optional AER capability.

A variable-length Package containing a list of Packages , each containing a single PCI, PCI-X, PCI Express, or PCI Express Descriptor Record Setting as described below The _HPX object supersedes the _HPP object. If the _HPP and _HPX objects exist within a device’s scope, OSPM will only evaluate the _HPX object.

OSPM may override the settings provided by the _HPX object’s Type2 record (PCI Express Settings) or Type3 record (PCI Express Descriptor Settings) when OSPM has assumed native control of the corresponding feature. For example, if OSPM has assumed ownership of AER (via _OSC), OSPM may override AER related settings returned by _HPX.

Since error status registers do not drive error signaling, OSPM is not required to clear error status registers as part of _HPX handling.

There are other mechanisms besides _HPX that provide platform-specific information to the OSPM PCI driver component responsible for configuring PCI, PCI-X, or PCI Express Functions (e.g., _DSM Definitions for Latency Tolerance Reporting as defined in the PCI Firmware Specification). System firmware should only provide platform-specific information via one of these mechanisms for any given register or feature (i.e., if Latency Tolerance Reporting information is provided via _DSM Definitions for Latency Tolerance Reporting then no information related to Latency Tolerance Reporting should be provided by _HPX and vice versa). Failure to do so will result in undefined behavior from the OSPM.

6.2.9.1. PCI Setting Record (Type 0) ¶

The PCI setting record contains the setting type 0, the current revision 1 and the type/revision specific content: cache-line size, latency timer, SERR enable, and PERR enable values.

If the hot plug device includes bridge(s) in the hierarchy, the above settings apply to the primary side (command register) of the hot plugged bridge(s). The settings for the secondary side of the bridge(s) (Bridge Control Register) are assumed to be provided by the bridge driver.

The Type 0 record is applicable to hot plugged PCI, PCI-X and PCI Express devices. OSPM will ignore settings provided in the Type0 record that are not applicable (for example, Cache-line size and Latency Timer are not applicable to PCI Express).

6.2.9.2. PCI-X Setting Record (Type 1) ¶

The PCI-X setting record contains the setting type 1, the current revision 1 and the type/revision specific content: the maximum memory read byte count setting, the average maximum outstanding split transactions setting and the total maximum outstanding split transactions to be used when configuring PCI-X command registers for PCI-X buses and/or devices.

For simplicity, OSPM could use the Average Maximum Outstanding Split Transactions value as the Maximum Outstanding Split Transactions register value in the PCI-X command register for each PCI-X device. Another alternative is to use a more sophisticated policy and the Total Maximum Outstanding Split Transactions Value to gain even more performance. In this case, the OS would examined each PCI-X device that is directly attached to the host bridge, determine the number of outstanding split transactions supported by each device, and configure each device accordingly. The goal is to ensure that the aggregate number of concurrent outstanding split transactions does not exceed the Total Maximum Outstanding Split Transactions Value: an integer denoting the number of concurrent outstanding split transactions the host bridge can support (the minimum value is 1).

This object does not address providing additional information that would be used to configure registers in bridge devices, whether architecturally-defined or specification-defined registers or device specific registers. It is expected that a driver for a bridge would be the proper implementation mechanism to address both of those issues. However, such a bridge driver should have access to the data returned by the _HPX object for use in optimizing its decisions on how to configure the bridge. Configuration of a bridge is dependent on both system specific information such as that provided by the _HPX object, as well as bridge specific information.

6.2.9.3. PCI Express Setting Record (Type 2) ¶

The PCI Express setting record contains the setting type 2, the current revision 1 and the type/revision specific content (the control registers as listed in the table below) to be used when configuring registers in the Advanced Error Reporting Extended Capability Structure or PCI Express Capability Structure for the PCI Express devices.

The Type 2 Setting Record allows a PCI Express-aware OS that supports native hot plug to configure the specified registers of the hot plugged PCI Express device. A PCI Express-aware OS that has assumed ownership of native hot plug (via _OSC) but does not support or does not have ownership of the AER register set must use the data values returned by the _HPX object’s Type 2 record to program the AER registers of a hot-added PCI Express device. However, since the Type 2 record also includes register bits that have functions other than AER, OSPM must ignore values contained within this setting record that are not applicable.

To support PCIe RsvdP semantics for reserved bits, two values for each register are provided: an “AND mask” and an “OR mask”. Each bit understood by firmware to be RsvdP shall be set to 1 in the “AND mask” and 0 in the “OR mask”. Each bit that firmware intends to be configured as 0 shall be set to 0 in both the “AND mask” and the “OR mask”. Each bit that firmware intends to be configured a 1 shall be set to 1 in both the “AND mask” and the “OR mask”.

When configuring a given register, OSPM uses the following algorithm:

Read the register’s current value, which contains the register’s default value.

Perform a bit-wise AND operation with the “AND mask” from the table below.

Perform a bit-wise OR operation with the “OR mask” from the table below.

Override the computed settings for any bits if deemed necessary. For example, if OSPM is aware of an architected meaning for a bit that firmware considers to be RsvdP, OSPM may choose to override the computed setting for that bit. Note that firmware sets the “AND value” to 1 and the “OR value” to 0 for each bit that it considers to be RsvdP.

Write the end result value back to the register.

Note that the size of each field in the following table matches the size of the corresponding PCI Express register.

6.2.9.4. PCI Express Descriptor Setting Record (Type 3) ¶

The PCI Express Descriptor setting record contains the setting type 3, the current revision 1 and the type/revision specific content (the control registers as listed in the tables below) to be used when configuring registers in PCI Express Functions. There may be multiple PCI Express Descriptor setting records in a single _HPX object with the same or different revision. Each PCI Express Descriptor setting record shall contain at least one, and may contain more than one, PCI Express Register Descriptors as defined in PCI Express Register Descriptor .

The Type 3 Setting Record allows a PCI Express-aware OS to configure the indicated registers of the PCI Express Function. A PCI Express-aware OS that does not support or does not have ownership of a register in this record must use the data values returned by the _HPX object’s Type 3 record to program that register of a PCI Express Function that has lost its configuration space settings (e.g. a hot-added device, a device not configured by the platform firmware during initial system boot, a Device/Function that was reset via Secondary Bus Reset/Function Level Reset, Downstream Port Containment was triggered, etc.).

To support PCIe RsvdP semantics for reserved bits, two values for each register indicated by Write Register Offset are provided: a Write AND Mask and a Write OR Mask. Each bit understood by firmware to be RsvdP shall be set to 1 in the Write AND Mask and 0 in the Write OR Mask. Each bit that firmware intends to be configured as 0 shall be set to 0 in both the Write AND Mask and the Write OR Mask. Each bit that firmware intends to be configured a 1 shall be set to 1 in both the Write AND Mask and the Write OR Mask.

OSPM evaluates each PCI Express Register Descriptor in order starting with the first PCI Express Register Descriptor and continuing through the Nth PCI Express Register Descriptor as shown in PCI Express Descriptor Setting Record Content for each PCI Express Function that has lost its configuration space settings (e.g. a hot-added device, a device not configured by the platform firmware during initial system boot, a Device/Function that was reset via Secondary Bus Reset/Function Level Reset, Downstream Port Containment was triggered, etc.) in the scope of the _HPX method using the following algorithm:

Verify the PCI Express Register Descriptor applies to the PCI Express Function.

Read the PCI Express Function’s Device Type/Port from its PCI Express Capabilities Register.

Read the bit corresponding to the PCI Express Function’s Device Port/Type in the Device/Port Type from PCI Express Register Descriptor below.

If set to 0b, then the PCI Express Register Descriptor does not apply to the PCI Express Function and OSPM moves to the next Function in the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

If set to 1b, then continue to the next step.

Determine if the PCI Express Function is a non-SR-IOV Function, an SR-IOV Physical Function, or an SR-IOV Virtual Function.

Read the bit corresponding to the PCI Express Function’s type in the Function Type from PCI Express Register Descriptor below.

If set to 0b, then the PCI Express Register Descriptor does not apply to the PCI Express Function and OSPM moves to the next Function in the scope of the _HPX method or to the next PCI Express Register Descriptor if there are no more Functions.

If set to 1b, then the PCI Express Register Descriptor applies to the PCI Express Function and OSPM continues to the next step.

Read the Configuration Space Location from PCI Express Register Descriptor below.

If Configuration Space Location is 0, then the Match Register Offset and Write Register Offset field’s byte offset is relative to offset 0 of the Function’s configuration space.

If Configuration Space Location is 1, then the Match Register Offset and Write Register Offset field’s byte offset is relative to the starting offset of the Capability Structure indicated by PCIe Capability ID.

If the Capability ID is 01h (PCI Power Management Capability Structure) or 10h (PCI Express Capability Structure) then OSPM shall check the Capability Version of the Function’s Capability Structure against the PCIe Capability ID field. In the event that there are more than one PCI Express Register Descriptors for a given PCIe Capability ID with different PCIe Capability Versions, OSPM shall use the PCI Express Register Descriptors with the highest PCIe Capability Version supported by the Function.

There may be more than one instance of a Capability Structure that matches the indicated PCIe Capability ID. Continue to step 3 for each such instance. If no Capability Structures indicated by PCIe Capability ID are found, then start back at step 1 above for the next Function in the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

If Configuration Space Location is 2, then the Match Register Offset and Write Register Offset field’s byte offset is relative to the starting offset of the Extended Capability Structure indicated by PCIe Capability ID and PCIe Capability Version.

In the event that there are more than one PCI Express Register Descriptors for a given PCIe Capability ID with different PCIe Capability Versions, OSPM shall use the PCI Express Register Descriptors with the highest PCIe Capability Version supported by the Function.

There may be more than one instance of an Extended Capability Structure that matches the indicated PCIe Capability ID and PCIe Capability Version. Continue to step 3 for each such instance. If no Extended Capability Structures indicated by PCIe Capability ID and PCIe Capability Version are found, then start back at step 1 above for the next Function in the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

If Configuration Space Location is 3, then the Match Register Offset and Write Register Offset field’s byte offset is relative to the starting offset of the Extended Capability Structure indicated by PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, VSEC ID, and VSEC Rev.

Once the PCI Express Register Descriptors that match the PCIe Capability ID with the highest PCIe Capability Version supported by the Function are found, the OSPM shall use PCI Express Register Descriptors among those with the highest VSEC Rev supported by the Function.

There may be more than one instance of an Extended Capability Structure that matches the indicated PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, VSEC ID, and VSEC Rev. Continue to step 3 for each such instance. If no Extended Capability Structures indicated by PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, VSEC ID, and VSEC Rev are found, then start back at step 1 above for the next Function in the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

If Configuration Space Location is 4, then the Match Register Offset and Write Register Offset field’s byte offset is relative to the starting offset of the Extended Capability Structure indicated by PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, DVSEC ID, and DVSEC Rev.

Once the PCI Express Register Descriptors that match the PCIe Capability ID with the highest PCIe Capability Version supported by the Function are found, the OSPM shall use PCI Express Register Descriptors among those with the highest DVSEC Rev supported by the Function.

There may be more than one instance of an Extended Capability Structure that matches the indicated PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, DVSEC ID, and DVSEC Rev. Continue to step 3 for each such instance. If no Extended Capability Structures indicated by PCIe Capability ID, PCIe Capability Version, PCIe Vendor ID, DVSEC ID, and DVSEC Rev are found, then start back at step 1 above for the next Function in the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

Check the Match Register to see if the Write Register should be updated.

Read the current value from the register indicated by the Match Register Offset.

Perform a bit-wise AND operation on the result of step 3a with the Match AND Mask.

Compare the result of step 3b with the Match Value. If they are equal then continue to step 4, else start back at step 1 above for the next Function

In the scope of the _HPX method or the next PCI Express Register Descriptor if there are no more Functions.

Update the Write Register.

Read the current value from the register indicated by the Write Register Offset. Perform a bit-wise AND operation on the result of step 4a with the Write AND Mask. Perform a bit-wise OR operation on the result of step 4b with the Write OR Mask. Override the computed settings from step 4c for any bits if deemed necessary. For example, if OSPM is aware of an architected meaning for a bit that firmware considers to be RsvdP, OSPM may choose to override the computed setting for that bit. Note that firmware sets the Write AND Mask to 1 and the Write OR Mask to 0 for each bit that it considers to be RsvdP. Write the result of step 4d back to the register indicated by the Write Register Offset.

6.2.9.5. _HPX Example ¶

6.2.10. _mat (multiple apic table entry) ¶.

This optional object evaluates to a buffer returning data in the format of a series of Multiple APIC Description Table (MADT) APIC Structure entries. This object can appear under an I/O APIC or processor object definition as processors may contain Local APICs. Specific types of MADT entries are meaningful to (in other words, processed by) OSPM when returned via the evaluation of this object as described in Table 5.21 . Other entry types returned by the evaluation of _MAT are ignored by OSPM.

When _MAT appears under a Processor object, OSPM uses the ACPI processor ID in the entries returned from the object’s evaluation to identify the entries corresponding to either the ACPI processor ID of the Processor object or the value returned by the _UID object under a Processor device.

A Buffer containing a list of Interrupt Controller Structures.

Example ASL for _MAT usage:

6.2.11. _OSC (Operating System Capabilities) ¶

This optional object is a control method that is used by OSPM to communicate to the platform the feature support or capabilities provided by a device’s driver. This object is a child object of a device and may also exist in the \_SB scope, where it can be used to convey platform wide OSPM capabilities. When supported, _OSC is invoked by OSPM immediately after placing the device in the D0 power state. Device specific objects are evaluated after _OSC invocation. This allows the values returned from other objects to be predicated on the OSPM feature support / capability information conveyed by _OSC. OSPM may evaluate _OSC multiple times to indicate changes in OSPM capability to the device but this may be precluded by specific device requirements. As such, _OSC usage descriptions in ACPI-Defined Devices and Device-Specific Objects , or other governing specifications describe superseding device specific _OSC capabilities and / or preclusions.

_OSC enables the platform to configure its ACPI namespace representation and object evaluations to match the capabilities of OSPM. This enables legacy operating system support for platforms with new features that make use of new namespace objects that if exposed would not be evaluated when running a legacy OS. _OSC provides the capability to transition the platform to native operating system support of new features and capabilities when available through dynamic namespace reconfiguration. _OSC also allows devices with Compatible IDs to provide superset functionality when controlled by their native (For example, _HID matched) driver as appropriate objects can be exposed accordingly as a result of OSPM’s evaluation of _OSC.

Arguments: (4)

Arg0 - A Buffer containing a UUID Arg1 - An Integer containing a Revision ID of the buffer format Arg2 - An Integer containing a count of entries in Arg3 Arg3 - A Buffer containing a list of DWORD capabilities Return Value: A Buffer containing a list of capabilities

Argument Information

Arg0: UUID - used by the platform in conjunction with Revision ID to ascertain the format of the Capabilities buffer.

Arg1: Revision ID - The revision of the Capabilities Buffer format. The revision level is specific to the UUID.

Arg2: Count - Number of DWORDs in the Capabilities Buffer in Arg3

Arg3: Capabilities Buffer - Buffer containing the number of DWORDs indicated by Count. The first DWORD of this buffer contains standard bit definitions as described below. Subsequent DWORDs contain UUID-specific bits that convey to the platform the capabilities and features supported by OSPM. Successive revisions of the Capabilities Buffer must be backwards compatible with earlier revisions. Bit ordering cannot be changed.

Capabilities Buffers are device-specific and as such are described under specific device definitions. See ACPI-Defined Devices and Device-Specific Objects for any _OSC definitions for ACPI devices. The format of the Capabilities Buffer and behavior rules may also be specified by OEMs and IHVs for custom devices and other interface or device governing bodies for example, the PCI SIG.

The first DWORD in the capabilities buffer is used to return errors defined by _OSC. This DWORD must always be present and may not be redefined/reused by unique interfaces utilizing _OSC.

Bit [0]- Query Support Flag. If set, the _OSC invocation is a query by OSPM to determine or negotiate with the platform the combination of capabilities for which OSPM may take control. In this case, OSPM sets bits in the subsequent DWORDs to specify the capabilities for which OSPM intends to take control. If clear, OSPM is attempting to take control of the capabilities corresponding to the bits set in subsequent DWORDs. OSPM may only take control of capabilities as indicated by the platform by the result of the query.

Bit [1] - Always clear (0).

Bit [2] - Always clear (0).

Bit [3] - Always clear (0).

All others - reserved.

Return Value Information

Capabilities Buffer (Buffer) - The platform acknowledges the Capabilities Buffer by returning a buffer of DWORDs of the same length. Set bits indicate acknowledgment that OSPM may take control of the capability and cleared bits indicate that the platform either does not support the capability or that OSPM may not assume control.

Bit [0] - Reserved (not used)

Bit [1] - _OSC failure. Platform Firmware was unable to process the request or query. Capabilities bits may have been masked.

Bit [2] - Unrecognized UUID. This bit is set to indicate that the platform firmware does not recognize the UUID passed in via Arg0. Capabilities bits are preserved.

Bit [3] - Unrecognized Revision. This bit is set to indicate that the platform firmware does not recognize the Revision ID passed in via Arg1. Capabilities bits beyond those comprehended by the firmware will be masked.

Bit [4] - Capabilities Masked. This bit is set to indicate that capabilities bits set by driver software have been cleared by platform firmware.

OSPM must not use the results of _OSC evaluation to choose a compatible device driver. OSPM must use _HID, _CID, or native enumerable bus device identification mechanisms to select an appropriate driver for a device.

The platform may issue a Notify**(device, 0x08) to inform OSPM to re-evaluate _OSC when the availability of feature control changes. Platforms must **not **rely, however, on OSPM to evaluate _OSC after issuing a **Notify for proper operation as OSPM cannot guarantee the presence of a target entity to receive and process the Notify for the device. For example, a device driver for the device may not be loaded at the time the Notify is signaled. Further, the issuance and processing rules for notification of changes in the Capabilities Buffer is device specific. As such, the allowable behavior is governed by device specifications either in ACPI-Defined Devices and Device-Specific Objects , for ACPI-define devices, or other OEM, IHV, or device governing body’s’ device specifications.

It is permitted for _OSC to return all bits in the Capabilities Buffer cleared. An example of this is when significant time is required to disable platform-based feature support. The platform may then later issue a Notify to tell OSPM to re-evaluate _OSC to take over native control. This behavior is also device specific but may also rely on specific OS capability.

In general, platforms should support both OSPM taking and relinquishing control of specific feature support via multiple invocations of _OSC but the required behavior may vary on a per device basis.

Since platform context is lost when the platform enters the S4 sleeping state, OSPM must re-evaluate _OSC upon wake from S4 to restore the previous platform state. This requirement will vary depending on the device specific _OSC functionality.

6.2.11.1. Rules for Evaluating _OSC ¶

This section defines when and how the OS must evaluate _OSC, as well as restrictions on firmware implementation.

6.2.11.1.1. Query Flag ¶

If the Query Support Flag (Capabilities DWORD 1, bit 0 ) is set by the OS when evaluating _OSC, no hardware settings are permitted to be changed by firmware in the context of the _OSC call. It is strongly recommended that the OS evaluate _OSC with the Query Support Flag set until _OSC returns the Capabilities Masked bit clear, to negotiate the set of features to be granted to the OS for native support; a platform may require a specific combination of features to be supported natively by an OS before granting native control of a given feature. After negotiation with the query flag set, the OS should evaluate without it so that any negotiated values can be made effective to hardware.

6.2.11.1.2. Evaluation Conditions ¶

The OS must evaluate _OSC under the following conditions:

During initialization of any driver that provides native support for features described in the section above. These features may be supported by one or many drivers, but should only be evaluated by the main bus driver for that hierarchy. Secondary drivers must coordinate with the bus driver to install support for these features. Drivers may not relinquish control of features previously obtained (i.e., bits set in Capabilities DWORD3 after the negotiation process must be set on all subsequent negotiation attempts.)

When a Notify(<device>, 8) is delivered to the PCI Host Bridge device.

Upon resume from S4. Platform firmware will handle context restoration when resuming from S1-S3.

6.2.11.1.3. Sequence of _OSC Calls ¶

The following rules govern sequences of calls to _OSC that are issued to the same host bridge and occur within the same boot.

The OS is permitted to evaluate _OSC an arbitrary number of times.

If the OS declares support of a feature in the Support Field in one call to _OSC, then it must preserve the set state of that bit (declaring support for that feature) in all subsequent calls.

If the OS is granted control of a feature in the Control Field in one call to _OSC, then it must preserve the set state of that bit (requesting that feature) in all subsequent calls.

Firmware may not reject control of any feature it has previously granted control to.

There is no mechanism for the OS to relinquish control of a feature previously requested and granted.

6.2.11.2. Platform-Wide OSPM Capabilities ¶

OSPM evaluates \_SB._OSC to convey platform-wide OSPM capabilities to the platform. Argument definitions are as follows:

Arguments(4) :

Arg0 - UUID (Buffer): 0811B06E-4A27-44F9-8D60-3CBBC22E7B48 Arg1 - Revision ID (Integer): 1 Arg2 - Count of Entries in Arg3 (Integer): 2 Arg3 - DWORD capabilities (Buffer): First DWORD: as described in Section 6.2.11 Second DWORD: see the following table.

* As part of the handshake provided through _OSC, the OS will pass in flags to indicate whether it supports Platform Coordinated Low Power Idle or OS Initiated Low Power Idle or both (see Section 8.4.4.2 ), through flags 7 and 8. The platform will indicate which of the modes it supports in its response by clearing flags that are not supported. If both are supported, the default is platform coordinated and OSPM can switch the platform to OS Initiated via a processor architecture specific mechanism. By setting either flag 7 or 8 or both, the OSPM is asserting it supports any objects associated with Low Power Idle states (see Section 8.4.4.3 , Table 8.16 , and Section 7.2.5 ), and supports a Processor Container Device .

Capabilities Buffer (Buffer) - The platform acknowledges the Capabilities Buffer by returning a buffer of DWORDs of the same length. Set bits indicate acknowledgment and cleared bits indicate that the platform does not support the capability.

6.2.11.3. Operating System Capabilities (_OSC) for USB ¶

Platform hardware and operating systems with support for USB4 require a few controls for passing information back and forth. The following definition is used to convey this information.

Along with the Platform-Wide OSPM Capabilities defined in Section 6.2.11.2 , this _OSC interface is implemented within the same scope, and therefore the same _OSC Control Method, using a different UUID value. If the platform does not support USB4, the UUID defined in this section should not be supported.

Note that if control of any features described in Table 6.15 are granted to OSPM, system firmware must not attempt to control any other features not granted to OSPM; only one Connection Manager is permitted to be active at any point in time. OSPM evaluates \_SB._OSC to manage USB capabilities within the platform. Argument definitions are as follows.

Arguments (4):

Arg0 – UUID (Buffer): 23A0D13A-26AB-486C-9C5F-0FFA525A575A

Arg1 – Revision ID (Integer): 1

Arg2 – Count of entries (DWORDS) in Arg3 (Integer): 3

Arg3 – DWORD capabilities buffer:

First DWORD: As described in Section 6.2.11.1 Second DWORD: OSPM Support Field for USB. See Table 6.14 for details. Third DWORD: OSPM Control Field for USB. See Table 6.15 for details.

Note: OSPM must re-invoke _OSC during S4 resume.

Capabilities Buffer (Buffer): The platform acknowledges the Capabilities Buffer by returning a buffer of DWORDs of the same length. Preserved bits in the Control Field convey control from the platform to OSPM, while masked/cleared bits in the Control Field indicate that the platform does not permit OSPM control of the respective capability or feature.

6.2.12. _PRS (Possible Resource Settings) ¶

This optional object evaluates to a byte stream that describes the possible resource settings for the device. When describing a platform, specify a _PRS for all the configurable devices. Static (non-configurable) devices do not specify a _PRS object. The information in this package is used by OSPM to select a conflict-free resource allocation without user intervention. This method must not reference any operation regions that have not been declared available by a _REG method.

The format of the data in a _PRS object follows the same format as the _CRS object (for more information, see Section 6.2.2 ).

If the device is disabled when _PRS is called, it must remain disabled.

A Buffer containing a Resource Descriptor byte stream

6.2.13. _PRT (PCI Routing Table) ¶

PCI interrupts are inherently non-hierarchical. PCI interrupt pins are wired to interrupt inputs of the interrupt controllers. The _PRT object provides a mapping from PCI interrupt pins to the interrupt inputs of the interrupt controllers. The _PRT object is required under all PCI root bridges. _PRT evaluates to a package that contains a list of packages, each of which describes the mapping of a PCI interrupt pin.

A Package containing variable-length list of PCI interrupt mapping packages, as described below

The PCI function number in the Address field of the _PRT packages must be 0xFFFF, indicating “any” function number or “all functions”.

The _PRT mapping packages have the fields listed in the table below.

There are two ways that _PRT can be used. Typically, the interrupt input that a given PCI interrupt is on is configurable. For example, a given PCI interrupt might be configured for either IRQ 10 or 11 on an 8259 interrupt controller. In this model, each interrupt is represented in the ACPI namespace as a PCI Interrupt Link Device.

These objects have _PRS, _CRS, _SRS, and _DIS control methods to allocate the interrupt. Then, OSPM handles the interrupts not as interrupt inputs on the interrupt controller, but as PCI interrupt pins. The driver looks up the device’s pins in the _PRT to determine which device objects allocate the interrupts. To move the PCI interrupt to a different interrupt input on the interrupt controller, OSPM uses _PRS, _CRS, _SRS, and _DIS control methods for the PCI Interrupt Link Device.

In the second model, the PCI interrupts are hardwired to specific interrupt inputs on the interrupt controller and are not configurable. In this case, the Source field in _PRT does not reference a device, but instead contains the value zero, and the Source Index field contains the global system interrupt to which the PCI interrupt is hardwired.

6.2.13.1. Example: Using _PRT to Describe PCI IRQ Routing ¶

The following example describes two PCI slots and a PCI video chip. Notice that the interrupts on the two PCI slots are wired differently (barber-poled):

6.2.14. _PXM (Proximity) ¶

This optional object is used to describe proximity domain associations within a machine. _PXM evaluates to an integer that identifies a device as belonging to a Proximity Domain defined in the System Resource Affinity Table (SRAT). OSPM assumes that two devices in the same proximity domain are tightly coupled. OSPM could choose to optimize its behavior based on this. For example, in a system with four processors and six memory devices, there might be two separate proximity domains (0 and 1), each with two processors and three memory devices. In this case, the OS may decide to run some software threads on the processors in proximity domain 0 and others on the processors in proximity domain 1. Furthermore, for performance reasons, it could choose to allocate memory for those threads from the memory devices inside the proximity domain common to the processor and the memory device rather than from a memory device outside of the processor’s proximity domain.

Children of a device belong to the same proximity domain as their parent unless they contain an overriding _PXM. Proximity domains do not imply any ejection relationships.

OSPM shall make no assumptions about the proximity or nearness of different proximity domains. The difference between two integers representing separate proximity domains does not imply distance between the proximity domains (in other words, proximity domain 1 is not assumed to be closer to proximity domain 0 than proximity domain 6).

If the Local APIC ID / Local SAPIC ID / Local x2APIC ID or the GICC ACPI Processor UID of a dynamically added processor is not present in the System Resource Affinity Table (SRAT), a _PXM object must exist for the processor’s device or one of its ancestors in the ACPI Namespace. See Section 5.2.16 for more information.

An Integer (DWORD) containing a proximity domain identifier.

6.2.15. _SLI (System Locality Information) ¶

The System Locality Information Table (SLIT) table defined in Generic Initiator Affinity Structure provides relative distance information between all System Localities for use during OS initialization.

The value of each Entry[ i,j ] in the SLIT table, where i represents a row of a matrix and j represents a column of a matrix, indicates the relative distances from System Locality / Proximity Domain i to every other System Locality j in the system (including itself).

The i,j row and column values correlate to the value returned by the _PXM object in the ACPI namespace. See _PXM (Proximity) for more information.

Dynamic runtime reconfiguration of the system may cause the distance between System Localities to change.

_SLI is an optional object that enables the platform to provide the OS with updated relative System Locality distance information at runtime. _SLI provide OSPM with an update of the relative distance from System Locality i to all other System Localities in the system.

A Buffer containing a system locality information table

If System Locality i >= N, where N is the number of System Localities, the _SLI method returns a buffer that contains these relative distances:

If System Locality i < N, the _SLI method returns a buffer that contains these relative distances:

( i, i ) is always a value of 10.

Fig. 6.5 System Locality information Table ¶

The System Locality information Table diagrams a 4-node system where the nodes are numbered 0 through 3 (Node n = Node 3) and the granularity is at the node level for the NUMA distance information. In this example we assign System Localities / Proximity Domain numbers equal to the node numbers (0-3). The NUMA relative distances between proximity domains as implemented in this system are described in the matrix represented in Example Relative Distances Between Proximity Domains . Proximity Domains are represented by the numbers in the top row and left column. Distances are represented by the values in cells internal in the table from the domains.

An example of these distances between proximity domains encoded in a System Locality Information Table for consumption by OSPM at boot time is described in the table below.

If a new “Node 4” is added, then the following table represents the updated system’s NUMA relative distances of proximity domains.

The new node’s _SLI object would evaluate to a buffer containing [17,21,14,23,10,17,21,14,23,10].

Some systems support interleave memory across the nodes. The SLIT representation of these systems is implementation specific.

6.2.16. _SRS (Set Resource Settings) ¶

This optional control method takes one byte stream argument that specifies a new resource allocation for a device. The resource descriptors in the byte stream argument must be specified exactly as listed in the _CRS byte stream - meaning that the identical resource descriptors must appear in the identical order, resulting in a buffer of exactly the same length. Optimizations such as changing an IRQ descriptor to an IRQNoFlags descriptor (or vice-versa) must not be performed. Similarly, changing StartDependentFn to StartDependentFnNoPri is not allowed. A _CRS object can be used as a template to ensure that the descriptors are in the correct format. For more information, see the _CRS object definition.

The settings must take effect before the _SRS control method returns.

This method must not reference any operation regions that have not been declared available by a _REG method.

If the device is disabled, _SRS enables the device at the specified resources. _SRS is not used to disable a device; use the _DIS control method instead.

Arguments: (1)

Arg0 - A Buffer containing a Resource Descriptor byte stream

6.2.17. _CCA (Cache Coherency Attribute) ¶

The _CCA object returns whether or not a bus-master device supports hardware managed cache coherency. Expected values are 0 to indicate it is not supported, and 1 to indicate that it is supported. All other values are reserved.

On platforms for which existing default cache-coherency behavior of the OS is not adequate, _CCA enables the OS to adapt to the differences. If used, _CCA must be included under all bus-master-capable devices defined as children of \_SB, to ensure that the operating system knows when it can rely on hardware managed cache coherency. The value of _CCA is inherited by all descendants of these devices, so it need not be repeated for their children devices and will be ignored by OSPM if it is provided there. This includes slave devices on a shared DMA controller; thus these DMA controllers must also be defined in the namespace under the System Bus and include a _CCA object.

If a device indicates it does not have hardware cache coherency support, then OSPM must use a software cache flushing algorithm to ensure stale or invalid data is not accessed from the caches.

__CCA objects are only relevant for devices that can access CPU-visible memory, such as devices that are DMA capable. On ARM based systems, the _CCA object must be supplied all such devices. On Intel platforms, if the _CCA object is not supplied, the OSPM will assume the devices are hardware cache coherent.

An Integer indicating the device’s support for hardware cache coherency: 0 - The device does not have hardware managed cache coherency 1 - The device has hardware managed cache coherency Other Values - Reserved

There are restrictions related to when this object is evaluated which have implications for implementing this object as a control method. The _CCA method must only access Operation Regions that have been indicated to be available as defined by the _REG method. The _REG method is described in _REG (Region) .

6.2.17.1. _CCA Example ASL: ¶

6.2.18. _hma(heterogeneous memory attributes) ¶.

The Heterogeneous Memory Attributes Table (HMAT) defined in Heterogeneous Memory Attribute Table (HMAT) provides Heterogeneous Memory Attributes. Dynamic runtime reconfiguration of the system may cause proximities domains or memory attributes to change. If the “Reservation Hint” is set, new HMAT update shall not reset the “Reservation Hint” unless the memory range is removed.

_HMA is an optional object that enables the platform to provide the OS with updated Heterogeneous Memory Attributes information at runtime. _HMA provides OSPM with the latest HMAT in entirety overriding existing HMAT.

A Buffer containing entire HMAT.

Example ASL for _HMA usage:

6.3. Device Insertion, Removal, and Status Objects ¶

The objects defined in this section provide mechanisms for handling dynamic insertion and removal of devices and for determining device and notification processing status.

Device insertion and removal objects are also used for docking and undocking mobile platforms to and from a peripheral expansion dock. These objects give information about whether or not devices are present, which devices are physically in the same device (independent of which bus the devices live on), and methods for controlling ejection or interlock mechanisms.

The system is more stable when removable devices have a software-controlled, VCR-style ejection mechanism instead of a “surprise-style” ejection mechanism. In this system, the eject button for a device does not immediately remove the device, but simply signals the operating system. OSPM then shuts down the device, closes open files, unloads the driver, and sends a command to the hardware to eject the device.

If the device is physically inserted while the system is in the working state (in other words, hot insertion), the hardware generates a general-purpose event.

The control method servicing the event uses the Notify(device,0) command to inform OSPM of the bus that the new device is on or the device object for the new device. If the Notify command points to the device object for the new device, the control method must have changed the device’s status returned by _STA to indicate that the device is now present. The performance of this process can be optimized by having the object of the Notify as close as possible, in the namespace hierarchy, to where the new device resides. The Notify command can also be used from the _WAK control method (see Section 7.4.5 ) to indicate device changes that may have occurred while the system was sleeping. For more information about the Notify command, see Section 5.6.6 .

OSPM uses the identification and configuration objects to identify, configure, and load a device driver for the new device and any devices found below the device in the hierarchy.

If the device has a _LCK control method, OSPM may later run this control method to lock the device.

The new device referred to in step 2 need not be a single device, but could be a whole tree of devices. For example, it could point to the PCI-PCI bridge docking connector. OSPM will then load and configure all devices it found below that bridge. The control method can also point to several different devices in the hierarchy if the new devices do not all live under the same bus. (in other words, more than one bus goes through the connector).

For removing devices, ACPI supports both hot removal (system is in the S0 state), and warm removal (system is in a sleep state: S1-S4). This is done using the _EJx control methods. Devices that can be ejected include an _EJx control method for each sleeping state the device supports (a maximum of 2 _EJx objects can be listed). For example, hot removal devices would supply an _EJ0; warm removal devices would use one of _EJ1-EJ4. These control methods are used to signal the hardware when an eject is to occur.

The sequence of events for dynamically removing a device goes as follows:

The eject button is pressed and generates a general-purpose event. (If the system was in a sleeping state, it should wake the system).

The control method for the event uses the Notify(device, 3) command to inform OSPM which specific device the user has requested to eject. Notify does not need to be called for every device that may be ejected, but for the top-level device. Any child devices in the hierarchy or any ejection-dependent devices on this device (as described by _EJD, below) are automatically removed.

The OS shuts down and unloads devices that will be removed.

If the device has a _LCK control method, OSPM runs this control method to unlock the device.

The OS looks to see what _EJx control methods are present for the device. If the removal event will cause the system to switch to battery power (in other words, an undock) and the battery is low, dead, or not present, OSPM uses the lowest supported sleep state _EJx listed; otherwise it uses the highest state _EJx. Having made this decision, OSPM runs the appropriate _EJx control method to prepare the hardware for eject.

Warm removal requires that the system be put in a sleep state. If the removal will be a warm removal, OSPM puts the system in the appropriate Sx state. If the removal will be a hot removal, OSPM skips to step 8, below.

For warm removal, the system is put in a sleep state. Hardware then uses any motors, and so on, to eject the device. Immediately after ejection, the hardware transitions the system to S0. If the system was sleeping when the eject notification came in, the OS returns the system to a sleeping state consistent with the user’s wake settings.

OSPM calls _STA to determine if the eject successfully occurred. (In this case, control methods do not need to use the Notify(device,3) command to tell OSPM of the change in _STA) If there were any mechanical failures, _STA returns 3: device present and not functioning, and OSPM informs the user of the problem.

This mechanism is the same for removing a single device and for removing several devices, as in an undock.

ACPI does not disallow surprise-style removal of devices; however, this type of removal is not recommended because system and data integrity cannot be guaranteed when a surprise-style removal occurs. Because the OS is not informed, its device drivers cannot save data buffers and it cannot stop accesses to the device before the device is removed. To handle surprise-style removal, a general-purpose event must be raised. Its associated control method must use the Notify command to indicate which bus the device was removed from.

The device insertion and removal objects are listed in the table below.

6.3.1. _EDL (Eject Device List) ¶

This object evaluates to a package of namespace references containing the names of device objects that depend on the device under which the _EDL object is declared. This is primarily used to support docking stations. Before the device under which the _EDL object is declared may be ejected, OSPM prepares the devices listed in the _EDL object for physical removal.

A variable-length Package containing a list of namespace references

Before OSPM ejects a device via the device’s _EJx methods, all dependent devices listed in the package returned by _EDL are prepared for removal. Notice that _EJx methods under the dependent devices are not executed.

When describing a platform that includes a docking station, an _EDL object is declared under the docking station device. For example, if a mobile system can attach to two different types of docking stations, _EDL is declared under both docking station devices and evaluates to the packaged list of devices that must be ejected when the system is ejected from the docking station.

An ACPI-compliant OS evaluates the _EDL method just prior to ejecting the device.

6.3.2. _EJD (Ejection Dependent Device) ¶

This object is used to specify the name of a device on which the device, under which this object is declared, is dependent. This object is primarily used to support docking stations. Before the device indicated by _EJD is ejected, OSPM will prepare the dependent device (in other words, the device under which this object is declared) for removal.

A String containing the device name

_EJD is evaluated once when the ACPI table loads. The EJx methods of the device indicated by _EJD will be used to eject all the dependent devices. A device’s dependents will be ejected when the device itself is ejected.

OSPM will not execute a dependent device’s _EJx methods when the device indicated by _EJD is ejected.

When describing a platform that includes a docking station, usually more than one _EJD object will be needed. For example, if a dock attaches both a PCI device and an ACPI-configured device to a mobile system, then both the PCI device description package and the ACPI-configured device description package must include an _EJD object that evaluates to the name of the docking station (the name specified in an _ADR or _HID object in the docking station’s description package). Thus, when the docking connector signals an eject request, OSPM first attempts to disable and unload the drivers for both the PCI and ACPI configured devices.

An ACPI 1.0 OS evaluates the _EJD methods only once during the table load process. This greatly restricts a table designer’s freedom to describe dynamic dependencies such as those created in scenarios with multiple docking stations. This restriction is illustrated in the example below; the _EJD information supplied via and ACPI 1.0-compatible namespace omits the IDE2 device from DOCK2’s list of ejection dependencies. Starting in ACPI 2.0, OSPM is presented with a more in-depth view of the ejection dependencies in a system by use of the _EDL methods.

An example use of _EJD and _EDL is as follows:

6.3.3. _EJx (Eject) ¶

These control methods are optional and are supplied for devices that support a software-controlled VCR-style ejection mechanism or that require an action be performed such as isolation of power/data lines before the device can be removed from the system. To support warm (system is in a sleep state) and hot (system is in S0) removal, an _EJx control method is listed for each sleep state from which the device supports removal, where x is the sleeping state supported. For example, _EJ0 indicates the device supports hot removal; _EJ1-EJ4 indicate the device supports warm removal.

Arg0 - An Integer containing a device ejection control 0 - Cancel a mark for ejection request (EJ0 will never be called with this value) 1 - Hot eject or mark for ejection

For hot removal, the device must be immediately ejected when OSPM calls the _EJ0 control method. The _EJ0 control method does not return until ejection is complete. After calling _EJ0, OSPM verifies the device no longer exists to determine if the eject succeeded. For _HID devices, OSPM evaluates the _STA method. For _ADR devices, OSPM checks with the bus driver for that device.

For warm removal, the _EJ1-_EJ4 control methods do not cause the device to be immediately ejected. Instead, they set proprietary registers to prepare the hardware to eject when the system goes into the given sleep state. The hardware ejects the device only after OSPM has put the system in a sleep state by writing to the SLP_EN register. After the system resumes, OSPM calls _STA to determine if the eject succeeded.

A device object may have multiple _EJx control methods. First, it lists an EJx control method for the preferred sleeping state to eject the device. Optionally, the device may list an EJ4 control method to be used when the system has no power (for example, no battery) after the eject. For example, a hot-docking notebook might list _EJ0 and _EJ4.

6.3.4. _LCK (Lock) ¶

This control method is optional and is required only for a device that supports a software-controlled locking mechanism. When the OS invokes this control method, the associated device is to be locked or unlocked based upon the value of the argument that is passed. On a lock request, the control method must not complete until the device is completely locked.

Arg0 - An Integer containing a device lock control 0 - Unlock the device 1 - Lock the device

When describing a platform, devices use either a _LCK control method or an _EJx control method for a device.

6.3.5. _OST (OSPM Status Indication) ¶

This object is an optional control method that is invoked by OSPM to indicate processing status to the platform. During device ejection, device hot add, Error Disconnect Recover, or other event processing, OSPM may need to perform specific handshaking with the platform. OSPM may also need to indicate to the platform its inability to complete a requested operation; for example, when a user presses an ejection button for a device that is currently in use or is otherwise currently incapable of being ejected. In this case, the processing of the ACPI Eject Request notification by OSPM fails. OSPM may indicate this failure to the platform through the invocation of the _OST control method. As a result of the status notification indicating ejection failure, the platform may take certain action including reissuing the notification or perhaps turning on an appropriate indicator light to signal the failure to the user.

Arguments: (3)

Arg0 - An Integer containing the source event Arg1 - An Integer containing the status code Arg2 - A Buffer containing status information

Argument Information:

Arg0 - source_event: DWordConst

If the value of source_event is <= 0xFF, this argument is the ACPI notification value whose processing generated the status indication. This is the value that was passed into the Notify operator.

If the value of source_event is 0x100 or greater then the OSPM status indication is a result of an OSPM action as indicated in OST Source Event Codes . For example, a value of 0x103 will be passed into _OST for this argument upon the failure of a user interface invoked device ejection.

If OSPM is unable to identify the originating notification value, OSPM invokes _OST with a value that contains all bits set (ones) for this parameter.

Arg1 – Status Code: DWordConst. OSPM indicates a notification value specific status. See Table 6.22 , Table 6.23 , and Table 6.25 for status code descriptions.

Arg2 - A buffer containing detailed OSPM-specific information about the status indication. This argument may be null.

6.3.5.1. Processing Sequence for Graceful Shutdown Request: ¶

Following receipt of the Graceful Shutdown Request (see Table 5.155 , value 0x81), the OS will be responsible for responding with one of the following status codes:

0x80 (OS Shutdown Request denied) - This value will be sent if the OS is not capable of performing a graceful shutdown.

0x81 (OS Shutdown in progress) - The OS has initiated the graceful shutdown procedure.

0x83 (OS Graceful Shutdown not supported) - The OS does not support the Graceful Shutdown Request.

If the OS does initiate a graceful shutdown it should continue to generate the “OS Shutdown in progress” message (_OST source event 0x100 status code 0x81) every 10 seconds. This functions as a heartbeat so that the service which requested the graceful shutdown knows that the request is currently being processed. The platform should assume that the OS shutdown is not proceeding if it does not receive the “OS Shutdown in progress” message for 60 seconds.

When the graceful shutdown procedure has completed the OSPM will send the “OS Shutdown completed” message and then transition the platform to the G2 “soft-off” power state.

It is possible for the platform to issue multiple notifications to OSPM and for OSPM to process the notifications asynchronously. As such, OSPM may invoke _OST for notifications independent of the order the notification are conveyed by the platform or by software to OSPM.

The figure below provides and example event flow of device ejection on a platform employing the _OST object.

Fig. 6.6 Device Ejection Flow Example Using _OST ¶

To maintain compatibility with OSPM implementations of previous revisions of the ACPI specification, the platform must not rely on OSPM’s evaluation of the _OST object for proper platform operation.

Example ASL for _OST usage:

6.3.5.2. Processing Sequence for Error Disconnect Recover ¶

If the OS attempts recovery operation following the receipt of the Error Disconnect Recover Request (see IPMI Status Codes , value 0x0F) the OS will be responsible for invoking _OST with one of the following status codes in the lower word of Arg1:

0x80 (Success) -This value will be sent if the OS successfully recovers all the child devices affected by Error Disconnect Recover, reconfigures then and brings them back to functional state. All child devices are accessible at the time _OST is evaluated.

0x81 (Not recovered) - The OS did not successfully recover one or more child devices that were affected by Error Disconnect Recover. Access to the child devices affected by Error Disconnect Recover may be unreliable.

The upper word of Arg1 can be used to communicate bus-specific status information.

6.3.6. _RMV (Remove) ¶

The optional _RMV object indicates to OSPM whether the device can be removed while the system is in the working state and does not require any ACPI system firmware actions to be performed for the device to be safely removed from the system (in other words, any device that only supports surprise-style removal). Any such removable device that does not have _LCK or _EJx control methods must have an _RMV object. This allows OSPM to indicate to the user that the device can be removed and to provide a way for shutting down the device before removing it. OSPM will transition the device into D3 before telling the user it is safe to remove the device.

This method is reevaluated after a device-check notification.

An Integer containing the device removal status: 0 - The device cannot be removed 1 - The device can be removed

Operating Systems implementing ACPI 1.0 interpret the presence of this object to mean that the device is removable.

6.3.7. _STA (Device Status) ¶

This object returns the current status of a device, which can be one of the following: enabled, disabled, or removed.

OSPM evaluates the _STA object before it evaluates a device _INI method. The return values of the Present and Functioning bits determines whether _INI should be evaluated and whether children of the device should be enumerated and initialized. See _INI (Init) .

If a device object describes a device that is not on an enumerable bus and the device object does not have an _STA object, then OSPM assumes that the device is present, enabled, shown in the UI, and functioning.

An Integer containing a device status bitmap: Bit [0] - Set if the device is present. Bit [1] - Set if the device is enabled and decoding its resources. Bit [2] - Set if the device should be shown in the UI. Bit [3] - Set if the device is functioning properly (cleared if device failed its diagnostics). Bit [4] - Set if the battery is present. Bits [31:5] - Reserved (must be cleared).

If bit [0] is cleared, then bit 1 must also be cleared (in other words, a device that is not present cannot be enabled).

A device can only decode its hardware resources if both bits 0 and 1 are set. If the device is not present (bit [0] cleared) or not enabled (bit [1] cleared), then the device must not decode its resources.

If a device is present in the machine, but should not be displayed in OSPM user interface, bit 2 is cleared. For example, a notebook could have joystick hardware (thus it is present and decoding its resources), but the connector for plugging in the joystick requires a port replicator. If the port replicator is not plugged in, the joystick should not appear in the UI, so bit [2] is cleared.

_STA may return bit 0 clear (not present) with bit [3] set (device is functional). This case is used to indicate a valid device for which no device driver should be loaded (for example, a bridge device.) Children of this device may be present and valid. OSPM should continue enumeration below a device whose _STA returns this bit combination.

Bit [4] of _STA applies only to the Control Method Battery Device (PNP0C0A). For all other devices, OSPM must ignore this bit.

If a device object (including the processor object) does not have an _STA object, then OSPM assumes that all of the above bits are set (i.e., the device is present, enabled, shown in the UI, and functioning).

6.4. Resource Data Types for ACPI ¶

The _CRS, _PRS, and _SRS control methods use packages of resource descriptors to describe the resource requirements of devices.

6.4.1. ASL Macros for Resource Descriptors ¶

ASL includes some macros for creating resource descriptors. The ASL syntax for these macros is defined in ASL Operator Reference , along with the other ASL operators.

6.4.2. Small Resource Data Type ¶

A small resource data type may be 2 to 8 bytes in size and adheres to the following format:

The following small information items are currently defined for Plug and Play devices:

6.4.2.1. IRQ Descriptor ¶

Type 0, Small Item Name 0x4, Length = 2 or 3

The IRQ data structure indicates that the device uses an interrupt level and supplies a mask with bits set indicating the levels implemented in this device. For standard PC-AT implementation there are 15 possible interrupts so a two-byte field is used. This structure is repeated for each separate interrupt required.

Low true, level sensitive interrupts may be electrically shared, but the process of how this might work is beyond the scope of this specification.

If byte 3 is not included, High true, edge sensitive, non-shareable is assumed.

See IRQ (Interrupt Resource Descriptor Macro) for a description of the ASL macros that create an IRQ descriptor.

6.4.2.2. DMA Descriptor ¶

Type 0, Small Item Name 0x5, Length = 2

The DMA data structure indicates that the device uses a DMA channel and supplies a mask with bits set indicating the channels actually implemented in this device. This structure is repeated for each separate channel required.

See DMA (DMA Resource Descriptor Macro) for a description of the ASL macro that creates a DMA descriptor.

6.4.2.3. Start Dependent Functions Descriptor ¶

Type 0, Small Item Name 0x6, Length = 0 or 1

Each logical device requires a set of resources. This set of resources may have interdependencies that need to be expressed to allow arbitration software to make resource allocation decisions about the logical device. Dependent functions are used to express these interdependencies. The data structure definitions for dependent functions are shown here. For a detailed description of the use of dependent functions refer to the next section.

Start Dependent Function fields may be of length 0 or 1 bytes. The extra byte is optionally used to denote the compatibility or performance/robustness priority for the resource group following the Start DF tag. The compatibility priority is a ranking of configurations for compatibility with legacy operating systems. This is the same as the priority used in the PNPBIOS interface. For example, for compatibility reasons, the preferred configuration for COM1 is IRQ4, I/O 3F8-3FF. The performance/robustness performance is a ranking of configurations for performance and robustness reasons. For example, a device may have a high-performance, bus mastering configuration that may not be supported by legacy operating systems. The bus-mastering configuration would have the highest performance/robustness priority while its polled I/O mode might have the highest compatibility priority.

If the Priority byte is not included, this indicates the dependent function priority is ‘acceptable’. This byte is defined as:

Notice that if multiple Dependent Functions have the same priority, they are further prioritized by the order in which they appear in the resource data structure. The Dependent Function that appears earliest (nearest the beginning) in the structure has the highest priority, and so on.

See StartDependentFn (Start Dependent Function Resource Descriptor Macro) for a description of the ASL macro that creates a Start Dependent Function descriptor.

6.4.2.4. End Dependent Functions Descriptor ¶

Type 0, Small Item Name 0x7, Length = 0

Only one End Dependent Function item is allowed per logical device. This enforces the fact that Dependent Functions cannot be nested.

See EndDependentFn (End Dependent Function Resource Descriptor Macro) for a description of the ASL macro that creates an End Dependent Functions descriptor.

6.4.2.5. I/O Port Descriptor ¶

Type 0, Small Item Name 0x8, Length = 7

There are two types of descriptors for I/O ranges. The first descriptor is a full function descriptor for programmable devices. The second descriptor is a minimal descriptor for old ISA cards with fixed I/O requirements that use a 10-bit ISA address decode. The first type descriptor can also be used to describe fixed I/O requirements for ISA cards that require a 16-bit address decode. This is accomplished by setting the range minimum base address and range maximum base address to the same fixed I/O value.

See IO (IO Resource Descriptor Macro) for a description of the ASL macro that creates an I/O Port descriptor.

6.4.2.6. Fixed Location I/O Port Descriptor ¶

Type 0, Small Item Name 0x9, Length = 3

This descriptor is used to describe 10-bit I/O locations.

See FixedIO (Fixed IO Resource Descriptor Macro) for a description of the ASL macro that creates a Fixed I/O Port descriptor.

6.4.2.7. Fixed DMA Descriptor ¶

Type 0, Small Item Name 0xA, Length = 5

The Fixed DMA descriptor provides a means for platforms to statically assign DMA request lines and channels to devices connected to a shared DMA controller. This descriptor differs from the DMA descriptor in that it supports many more DMA request lines and DMA controller channels, as well as a flexible mapping between the two. The width of the bus used for transfers to the device is also provided. This structure is repeated for each separate request line/channel pair required, and can only be used in the _CRS object. (Dynamic arbitration of Fixed DMA resource is not supported.)

6.4.2.8. Vendor-Defined Descriptor, Type 0 ¶

Type 0, Small Item Name 0xE, Length = 1 to 7

The vendor defined resource data type is for vendor use.

See VendorShort (Short Vendor Resource Descriptor) for a description of the ASL macro that creates a short vendor-defined resource descriptor.

6.4.2.9. End Tag ¶

Type 0, Small Item Name 0xF, Length = 1

The End tag identifies an end of resource data.

If the checksum field is zero, the resource data is treated as if the checksum operation succeeded. Configuration proceeds normally.

The End Tag is automatically generated by the ASL compiler at the end of the ResourceTemplate statement.

6.4.3. Large Resource Data Type ¶

To allow for larger amounts of data to be included in the configuration data structure the large format is shown below. This includes a 16-bit length field allowing up to 64 KB of data.

The following large information items are currently defined:

6.4.3.1. 24-Bit Memory Range Descriptor ¶

Type 1, Large Item Value 0x1

The 24-bit memory range descriptor describes a device’s memory range resources within a 24-bit address space

Address bits [7:0] of memory base addresses are assumed to be 0.

A Memory range descriptor can be used to describe a fixed memory address by setting the range minimum base address and the range maximum base address to the same value.

24-bit Memory Range descriptors are used for legacy devices.

Mixing of 24-bit and 32-bit memory descriptors on the same device is not allowed.

See Memory24 (Memory Resource Descriptor Macro) for a description of the ASL macro that creates a 24-bit Memory descriptor.

6.4.3.2. Vendor-Defined Descriptor, Type 1 ¶

Type 1, Large Item Value 0x4

This specification (ACPI) defines the UUID specific descriptor subtype field and the UUID field to address potential collision of the use of this descriptor. It is strongly recommended that all newly defined vendor descriptors use these fields prior to Vendor Defined Data.

See VendorLong for a description of the ASL macro that creates a long vendor-defined resource descriptor.

6.4.3.3. 32-Bit Memory Range Descriptor ¶

Type 1, Large Item Value 0x5

This memory range descriptor describes a device’s memory resources within a 32-bit address space.

See Memory32 (Memory Resource Descriptor Macro) for a description of the ASL macro that creates a 32-bit Memory descriptor.

6.4.3.4. 32-Bit Fixed Memory Range Descriptor ¶

Type 1, Large Item Value 0x6

See Memory32Fixed (Memory Resource Descriptor Macro) for a description of the ASL macro that creates a 32-bit Fixed Memory descriptor.

6.4.3.5. Address Space Resource Descriptors ¶

The QWORD, DWORD, WORD, and Extended Address Space Descriptors are general-purpose structures for describing a variety of types of resources. These resources also include support for advanced server architectures (such as multiple root buses), and resource types found on some RISC processors. These descriptors can describe various kinds of resources. The following table defines the valid combination of each field and how they should be interpreted.

6.4.3.5.1. QWord Address Space Descriptor ¶

Type 1, Large Item Value 0xA

The QWORD address space descriptor is used to report resource usage in a 64-bit address space (like memory and I/O).

See QWordIO, QWordMemory, and ASL_QWordAddressSpace for a description of the ASL macros that creates a QWORD Address Space descriptor.

6.4.3.5.2. DWord Address Space Descriptor ¶

Type 1, Large Item Value 0x7

The DWORD address space descriptor is used to report resource usage in a 32-bit address space (like memory and I/O).

See DWordIO, DWordMemory and ASL_DWordAddressSpace for a description of the ASL macro that creates a DWORD Address Space descriptor

6.4.3.5.3. Word Address Space Descriptor ¶

Type 1, Large Item Value 0x8

The WORD address space descriptor is used to report resource usage in a 16-bit address space (like memory and I/O).

This descriptor is exactly the same as the DWORD descriptor specified in End Dependent Functions Descriptor ; the only difference is that the address fields are 16 bits wide rather than 32 bits wide.

See WordIO, WordBusNumber, and ASL_WordAddressSpace for a description of the ASL macros that create a Word address descriptor.

6.4.3.5.4. Extended Address Space Descriptor ¶

Type 1, Large Item Value 0xB

The Extended Address Space descriptor is used to report resource usage in the address space (like memory and I/O).

See ExtendedSpace (Extended Address Space Resource Descriptor Macro) for a description of the ASL macro that creates an Extended Address Space descriptor.

6.4.3.5.4.1. Type Specific Attributes ¶

The meaning of the Type Specific Attributes field of the Extended Address Space Descriptor depends on the value of the Resource Type field in the descriptor. When Resource Type = 0 (memory resource), the Type Specific Attributes field values are defined per Memory Attribute Definitions in the UEFI Specification under section titled GetMemoryMap() .

6.4.3.5.5. Resource Type Specific Flags ¶

The meaning of the flags in the Type Specific Flags field of the Address Space Descriptors depends on the value of the Resource Type field in the descriptor. The flags for each resource type are defined in the following tables:

6.4.3.6. Extended Interrupt Descriptor ¶

Type 1, Large Item Value 0x9

The Extended Interrupt Descriptor is necessary to describe interrupt settings and possibilities for systems that support interrupts above 15.

To specify multiple interrupt numbers, this descriptor allows vendors to list an array of possible interrupt numbers, any one of which can be used.

Low true, level sensitive interrupts may be electrically shared, the process of how this might work is beyond the scope of this specification.

If the OS is running using the 8259 interrupt model, only interrupt number values of 0-15 will be used, and interrupt numbers greater than 15 will be ignored. See the Interrupt section for a description of the ASL macro that creates an Extended Interrupt descriptor.

6.4.3.7. Generic Register Descriptor ¶

Type 1, Large Item Value 0x2

The generic register descriptor describes the location of a fixed width register within any of the ACPI-defined address spaces. See Generic Register Descriptor for details.

See Release (Release a Mutex Synchronization Object) for a description of the Generic Register Resource Descriptor Macro.

6.4.3.8. Connection Descriptors ¶

General-purpose I/O (GPIO) and Simple Peripheral Bus (SPB) controllers are hardware resources provided in silicon solutions to enable flexible configuration of a broad range of system designs. These controllers can provide input, output, interrupt and serial communication connections to arbitrary devices in a system. The function to which one of these connections is put depends on the specific device involved and the needs of the platform design. In order to support mobile platform architectures, ACPI abstracts these connections as resources.

6.4.3.8.1. GPIO Connection Descriptor ¶

Type 1, Large Item Name 0xC

The GPIO Connection Descriptor describes connections between GPIO controllers and peripheral devices. Two types of GPIO connections can be described: IO connections and Interrupt connections, distinguished by the GPIO Connection Type value in the descriptor. GPIO controllers and the devices that connect to them may be located anywhere in the namespace, but the connection must be described in the peripheral device’s resource objects (PRS, _CRS, etc.).

6.4.3.8.2. GenericSerialBus Connection Descriptors ¶

Type 1, Large Item Value 0x0E

All Serial Bus Resource descriptors utilize the following format. For specific bus types, the type-specific fields are used.

6.4.3.8.2.1. I2C Serial Bus Connection Resource Descriptor ¶

6.4.3.8.2.2. spi serial bus connection resource descriptor ¶, 6.4.3.8.2.3. uart serial bus connection resource descriptor ¶, 6.4.3.8.2.4. camera serial interface (csi-2) connection resource descriptor ¶, 6.4.3.9. pin function descriptor ¶, 6.4.3.10. pin configuration descriptor ¶, 6.4.3.11. pin group descriptor ¶, 6.4.3.12. pin group function descriptor ¶, 6.4.3.13. pin group configuration descriptor ¶, 6.5. other objects and control methods ¶, 6.5.1. _ini (init) ¶.

_INI is a device initialization object that performs device specific initialization. This control method is located under a device object and is run only when OSPM loads a description table. There are restrictions related to when this method is called and governing writing code for this method. The _INI method must only access Operation Regions that have been indicated to available as defined by the _REG method. The _REG method is described in _REG (Region) . This control method is run before _ADR, _CID, _HID, _SUN, and _UID are run.

Before evaluating the _INI object, OSPM evaluates the _STA object for the device. If the _STA object does not exist for the device, the device is assumed to be both present and functional. If the _STA method indicates that the device is present, OSPM will evaluate the _INI for the device (if the _INI method exists) and will examine each of the children of the device for _INI methods. If the _STA method indicates that the device is not present and is not functional, OSPM will not run the _INI and will not examine the children of the device for _INI methods. If the _STA object evaluation indicates that the device is not present but is functional, OSPM will not evaluate the _INI object, but will examine each of the children of the device for _INI objects (see the description of _STA for the explanation of this special case.) If the device becomes present after the table has already been loaded, OSPM will not evaluate the _INI method, nor examine the children for _INI methods.

The OSPM performed _INI object actions based upon the _STA Present and Functional bits are summarized in the table below.

The _INI control method is generally used to switch devices out of a legacy operating mode. For example, platform boot firmware often configures CardBus controllers in a legacy mode to support legacy operating systems. Before enumerating the device with an ACPI operating system, the CardBus controllers must be initialized to CardBus mode. For such systems, the vendor can include an _INI control method under the CardBus controller to switch the device into CardBus mode.

In addition to device initialization, OSPM unconditionally evaluates an _INI object under the \_SB namespace, if present, at the beginning of namespace initialization.

6.5.2. _DCK (Dock) ¶

This control method is located in the device object that represents the docking station (that is, the device object with all the _EJx control methods for the docking station). The presence of _DCK indicates to the OS that the device is really a docking station.

_DCK also controls the isolation logic on the docking connector. This allows an OS to prepare for docking before the bus is activated and devices appear on the bus.

Arg0 - An Integer containing a docking action code 0 - Undock (isolate from connector) 1 - Dock (remove isolation from connector)

An Integer containing the docking status code 1 - Successful 0 - Failed

When _DCK is called with 0, OSPM will ignore the return value. The _STA object that follows the _EJx control method will notify whether or not the portable has been ejected.

6.5.3. _BDN (BIOS Dock Name) ¶

_BDN is used to correlate a docking station reported via ACPI and the same docking station reported via legacy interfaces. It is primarily used for upgrading over non-ACPI environments.

An Integer that contains the EISA Dock ID _BDN must appear under a device object that represents the dock, that is, the device object with _Ejx methods. This object must return a DWORD that is the EISA-packed DockID returned by the Plug and Play BIOS Function 5 (Get Docking Station Identifier) for a dock.

If the machine does not support PNPBIOS, this object is not required.

6.5.4. _REG (Region) ¶

The OS runs _REG control methods to inform AML code of a change in the availability of an operation region. When an operation region handler is unavailable, AML cannot access data fields in that region. (Operation region writes will be ignored and reads will return indeterminate data.)

Arguments: (2)

Arg0 – An Integer containing the Operation Region address space ID and optional supplementary qualifier (See Section 5.5.2.4 and Table 5.149 .) Arg1 - An Integer containing the handler connection code: 0 – disconnect the handler 1 – connect the handler

Except for the cases shown below, control methods must assume all operation regions are inaccessible until the _REG(RegionSpace, 1) method is executed, where RegionSpace is the address space ID, or the address space ID with an additional qualifier, depending on the operation region. For more information on which operation regions have address space qualifiers, see Access to Operation Regions . Once _REG has been executed for a particular operation region, indicating that the operation region handler is ready, a control method can access fields in the operation region. Conversely, control methods must not access fields in operation regions when _REG method execution has not indicated that the operation region handler is ready.

For example, until the Embedded Controller driver is ready, the control methods cannot access the Embedded Controller. Once OSPM has run _REG(EmbeddedControl, 1), the control methods can then access operation regions in Embedded Controller address space. Furthermore, if OSPM executes _REG(EmbeddedControl, 0), control methods must stop accessing operation regions in the Embedded Controller address space.

The exceptions for the above rule are:

OSPM must guarantee that the following operation regions are always accessible: StepNumList-1 OSPM must guarantee that the following operation regions are always accessible: PCI_Config operation regions on a PCI root bus containing a _BBN object. SystemIO operation regions. SystemMemory operation regions when accessing memory returned by the System Address Map Interfaces . Note Since the region types above are permanently available, no _REG methods are required, nor will OSPM evaluate any _REG methods that appear in the same scope as the operation region declaration(s) of these types. OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. These operation regions may become inaccessible after OSPM runs _REG(EmbeddedControl, 0).

Place _REG in the same scope as operation region declarations. The OS will run the _REG in a given scope when the operation regions declared in that scope are available for use.

When the PCI0 operation region handler is ready, OSPM will run the _REG method declared in PCI0 scope to indicate that PCI Config space operation region access is available within the PCI0 scope (in other words, OPR1 access is allowed). Finally, when the Embedded Controller operation region handler is ready, OSPM will run the _REG method in the EC0 scope to indicate that EC space operation region access is available within the EC0 scope (in other words, OPR4 access is allowed). It should be noted that PCI Config Space Operation Regions are ready as soon the host controller or bridge controller has been programmed with a bus number. PCI1’s _REG method would not be run until the PCI-PCI bridge has been properly configured. At the same time, the OS will also run ETH0’s _REG method since its PCI Config Space would be also available. The OS will again run ETH0’s _REG method when the ETH0 device is started. Also, when the host controller or bridge controller is turned off or disabled, PCI Config Space Operation Regions for child devices are no longer available. As such, ETH0’s _REG method will be run when it is turned off and will again be run when PCI1 is turned off.

The OS only runs _REG methods that appear in the same scope as operation region declarations that use the operation region type that has just been made available. For example, _REG in the EC device would not be run when the PCI bus driver is loaded since the operation regions declared under EC do not use any of the operation region types made available by the PCI driver (namely, config space, I/O, and memory).

6.5.5. _BBN (Base Bus Number) ¶

For multi-root PCI platforms, the _BBN object evaluates to the PCI bus number that the platform boot firmware assigns. This is needed to access a PCI_Config operation region for the specific bus. The _BBN object is located under a PCI host bridge and must be unique for every host bridge within a segment since it is the PCI bus number.

An Integer that contains the PCI bus number. The lower 8 bits of _BBN returned integer is the PCI Base Bus number. Other bits are reserved.

6.5.6. _SEG (Segment) ¶

The optional _SEG object is located under a PCI host bridge and evaluates to an integer that describes the PCI Segment Group (see PCI Firmware Specification v3.0). If _SEG does not exist, OSPM assumes that all PCI bus segments are in PCI Segment Group 0.

PCI Segment Group is purely a software concept managed by system firmware and used by OSPM. It is a logical collection of PCI buses (or bus segments). There is no tie to any physical entities. It is a way to logically group the PCI bus segments and PCI Express Hierarchies. _SEG is a level higher than _BBN.

PCI Segment Group supports more than 256 buses in a system by allowing the reuse of the PCI bus numbers. Within each PCI Segment Group, the bus numbers for the PCI buses must be unique. PCI buses in different PCI Segment Group are permitted to have the same bus number.

A PCI Segment Group contains one or more PCI host bridges.

The lower 16 bits of _SEG returned integer is the PCI Segment Group number. Other bits are reserved.

6.5.7. _GLK (Global Lock) ¶

This optional named object is located within the scope of a device object. This object returns a value that indicates to any entity that accesses this device (in other words, OSPM or any device driver) whether the Global Lock must be acquired when accessing the device. OS-based device accesses must be performed while in acquisition of the Global Lock when potentially contentious accesses to device resources are performed by non-OS code, such as System Management Mode (SMM)-based code in Intel architecture-based systems.

Default behavior: if _GLK is not present within the scope of a given device, then the Global Lock is not required for that device.

An Integer that contains the Global Lock requirement code: 0 - The Global Lock is not required for this device 1 - The Global lock is required for this device

An example of device resource contention is a device driver for an SMBus-based device contending with SMM-based code for access to the Embedded Controller, SMB-HC, and SMBus target device. In this case, the device driver must acquire and release the Global Lock when accessing the device to avoid resource contention with SMM-based code that accesses any of the listed resources.

6.5.8. _DEP (Operation Region Dependencies) ¶

_DEP evaluates to a package and designates device objects that OSPM should assign a higher priority in start ordering due to future operation region accesses.

To increase the likelihood that an SPB operation region handler is available when needed, OSPM needs to know in advance which methods will access it – _DEP provides OSPM with this information. While the _DEP keyword may be used to determine start ordering, only the _REG method ( _REG (Region) ) callbacks can be relied upon to determine whether a region is accessible at a given point in time.

A variable-length Package containing object references.

6.5.9. _FIT (Firmware Interface Table) ¶

This method evaluates to a buffer returning data in the format of a series of NFIT Structures (See NVDIMM Firmware Interface Table (NFIT) ). This method may appear under the NVDIMM root device (see NVDIMM Root Device ). The _FIT method, when present, is always evaluated by OSPM.

_FIT returns all the entries in the NFIT.

The NFIT Update Notification notification value for the NVDIMM root device (see NVDIMM Root Device Notification Values ) notifies OSPM that it needs to re-evaluate the _FIT method.

NFIT is an ACPI table enumerated at OS boot. In case of hot plug of NVDIMMs, the corresponding NFIT structures will not be present in NFIT. _FIT method is also used to provide these structures dynamically during hot plug.

A Buffer containing a list of NFIT Structures

Example ASL for _FIT usage:

6.5.10. NVDIMM Label Methods ¶

The following table outlines the NVDIMM Label methods that are attached to the NVDIMM object.

6.5.10.1. _LSI (Label Storage Information) ¶

This optional object returns information about the Label Storage Area for the requested device.

A Package containing the Label Storage Area information as described below

_LSI returns a package in the format below:

6.5.10.2. _LSR (Label Storage Read) ¶

This optional object returns label data from the Label Storage Area starting at the specified offset.

Arg0 - Offset (Integer(DWORD) the byte offset in the Label Storage Area to start reading from Arg1 - TransferLength (Integer(DWORD) the number of bytes to transfer from the Label Storage Area. A TransferLength of 0 reads no data.

A Package containing label data from the Label Storage Area as described below

_LSR returns a package in the format below:

6.5.10.3. _LSW (Label Storage Write) ¶

This optional object writes label data to the Label Storage Area starting at the specified offset.

Arguments :

Arg0 - Offset (Integer(DWORD) the byte offset in the Label Storage Area to which the Label Data is to be written to the target NVDIMM Arg1 - TransferLength (Integer(DWORD) the number of bytes to transfer to the Label Storage Area. A TransferLength of 0 writes no data. Arg2 - LabelData (Buffer) the label data to write in to the Label Storage Area. The size of the LabelData is as indicated by TransferLength field above. The format of the Label Storage Area data is defined in UEFI.

Return Value :

An Integer (DWORD) containing the status of the _LSW as follows:

0x00000000 - Success

0x00000001 - Failure

0x00000002 - Invalid Input Parameters:

Offset > SizeOfLabelStorageArea reported with _LSI

Offset + TransferLength > SizeOfLabelStorageArea reported with _LSI

TransferLength > MaxTransferLength reported with _LSI

0x00000003 - Label Storage Area is locked and cannot be accessed

0x00000004 - HW failure prevented data from being written

Note: Any other non-zero values indicate a failure.

6.5.11. _CBR (CXL Host Bridge Register Info) ¶

This object is an optional control method that is invoked by OSPM to determine the memory location of CXL Host Bridge Registers and the version that represents the register layout. The _CBR object is located under a CXL Host Bridge Device and must return unique value for every CXL Host Bridge instance within a system.

For CXL host bridges that are present at boot time, CEDT shall provide the Host bridge register base address. The _UID object is required in the Host Bus Device in order to allow OSPM to match entries in the CEDT to devices present in the ACPI namespace.

For more information on CEDT, see http://uefi.org/acpi for the heading “CXL Early Discovery Table”.

A package containing the CXL Host Bridge Register Information as described below:

Note: Links to the CXL 1.1 and CXL 2.0 Specifications can be found at http://uefi.org/acpi , under the corresponding headings for each spec.

• Forums Trending Search forums
• What's new New posts Latest activity
• Members Current visitors

Interrupt/routing tables, where are they?

• Thread starter SkaarjMaster
• Start date Jul 30, 2003
• Hardware and Technology
• Motherboards

SkaarjMaster

Senior member.

• Jul 30, 2003

Assigned PCI interrupt tables, IRQ routing tables, interrupt pin assignment tables, whatever they're called they are pretty scarce lately. I know these days that there is less of a concern about assigned IRQs and stuff because of XP, but why don't motherboard manufacturers include this information in their manuals. I know Asus and a few others included this in the past, but I don't see much of this anymore. The old viahardware site (now sudhian) has some old ones for some older Abit and Shuttle boards, but how do I find the Assigned PCI Interrupt Tables/IRQ Routing Tables for the newer motherboards? I've checked some motherboard sites with no luck. Thanks for any help on this matter.  

Elite Member

It's because it doesn't matter at all. IRQ sharing is a ridiculously overhyped non-issue, being a mandatory part of PCI specification ever since (at least) PCI 2.0 which first appeared in 1993. But if you desperately WANT to know, use a utility program that reads out the PIC and APIC (not ACPI!) routing tables for you. For the former, browse the web for Craig Hart's PCI diagnostics tool. This is a DOS program, and when invoked with /P switch, also decodes the PIC IRQ routing table for you. Reading the APIC routing table is a tad more complicated, I have not seen a public tool for this yet.  

Yes, i want to know, but before I buy the motherboards. You see depending on the chipset or motherboard, the interrupts may be different. With video and sound cards taking up more than one slot these days, it could become an issue. That's why I would like to know ahead of time. Thanks for any more info. you can provide.  

Well, I just found out that Soyo has this "PCI IRQ Assignment" table (Soyo's term for it) in their manuals of their newer motherboards for download at their web site. Anyone know about any of the other manufacturers?  

• Jul 31, 2003

Peter, that's all good and well, but why not try and get everything on it's own IRQ as much as possible anyway (that's what I like to do and I'll try it again with XP in about 6 months with my new system). Let's see someone try to run a graphics intensive video game with their AGP video card and PCI sound card on the same IRQ; there will be issues one way or another. As far as shared IRQs never being an issue, where have you been for the past 5 years? Stoned?! Anyway, you have your views and I have mine, so let's leave it at that. Anyone else know about where to find these tables for other MB manufacturers besides Soyo?  

No, I've been designing PC mainboards. Nuff said.  

That's all fine and dandy Mr. Board Designer God, but being asleep for the past 5 years you obviously have been oblivious to the fact that numerous people have had IRQ sharing problems. Whether you have any secrets or not to get around the issue or are just referring to the XP operating system, you cannot escape the fact that this has been an issue in the past, continues to be an issue and will continue to be an issue in the future. Now, apparently, XP and some motherboard designs have done a lot to minimize this issue, but it still exists. Yes, it is a bit overhyped, but it remains an issue. Anyone else that wants to jump in this thread, please feel free. All I was asking for was access to PCI IRQ Assignment tables and I get bashed by someone who is obviously clueless to the IRQ issue. It's people like you that ruin the forum experience. Why don't you go bash some other thread a**hole!  

• Aug 1, 2003

No, sorry, I'm in touch with customers (and our customer support) well enough to have learnt that every and all perceived "IRQ sharing problems" boiled down to being mere crap driver problems. This is particularly true in the sound department, Creative standing out as the prime producer of drivers with messy interrupt handlers. With properly written drivers, I've seen as many as 20 devices of all kinds mangled onto one IRQ, system working fine. (Our boards aren't the usual kind, we have up to seven onboard devices and up to 14 slots, all of which can carry multiple PCI devices.) I know that stuff from the inside. Now since you've chosen to continue insulting me rather than listen, I'll be off this thread. Moderators shall be informed.  

DieHardware

Golden member.

Originally posted by: SkaarjMaster That's all fine and dandy Mr. Board Designer God, but being asleep for the past 5 years you obviously have been oblivious to the fact that numerous people have had IRQ sharing problems. Whether you have any secrets or not to get around the issue or are just referring to the XP operating system, you cannot escape the fact that this has been an issue in the past, continues to be an issue and will continue to be an issue in the future. Now, apparently, XP and some motherboard designs have done a lot to minimize this issue, but it still exists. Yes, it is a bit overhyped, but it remains an issue. Anyone else that wants to jump in this thread, please feel free. All I was asking for was access to PCI IRQ Assignment tables and I get bashed by someone who is obviously clueless to the IRQ issue. It's people like you that ruin the forum experience. Why don't you go bash some other thread a**hole! Click to expand...

Bye Peter. Bye DieHardware. It's really a shame the response I got in this forum in this thread from close minded people. I've gotten such a better response from other forums. I thought Anandtech was a decent forum, but I guess I was mistaken.  

KF, the voice of reason. Thanks for your input, my faith in AnandTech has been restored!  

Right so far. Only that chipsets do not per se have four PCI interrupt lines - in fact it's anywhere between 1 and over 100 (!). Mainboard designers are free to choose what lines to use for what, and the choice is arbitrary anyhow since it makes no difference other than electrical properties. The only given is what lines are used by chipset internal devices. ACPI is a better interface between BIOS and operating system, and enables the OS to know and see things only BIOS knew in previous software architectures. It doesn't change the way interrupt signalling works at all. Outside DOSish environments, interrupt request handlers are always the property of the operating system, who then dispatches to device drivers registered for that vector. Now what DOES change it is the appearance of APIC interrupt controllers in newer systems. Here, every PCI interrupt input is a separate, dedicated event, signalled to the CPU without the help of the ancient PIC interrupt controllers. This is faster, by eliminating the PIC interrupt signalling as the slowest link - but you still get interrupt line sharing in loaded systems, even if you are on an E7501 chipset with 104 interrupt lines. The number of APIC interrupt lines depends on the chipset's implementation - you always have 16 inputs for the legacy IRQs, and then as many PCI IRQ inputs as the chipset implements, again, from 1 to over 100. So KF, it's the other way round. The PCI IRQs go directly into the APIC(s), who signal them to the CPU(s). There isn't any programmable routing in that at all. As long as you're not running APIC mode, all the PCI IRQ lines are routed back to the legacy PICs, and pile up on the usual 15 IRQs. THIS is programmable.  

I don't have as much knowledge about specifically how interrupt controllers work as Peter or KF, but I can say that I've seen the debate about whether or not IRQ sharing is an issue many times over the last several years. It usually goes much like the conversation between Peter and SkaarjMaster. Somebody says something like device x and y don't work together when they share an IRQ. Somebody else then says almost exactly what Peter did, saying that IRQ sharing has been a part of PCI for 10 years, so it can't possibly be an issue. From my experience building and working on PCs, I know one simple fact about interrupt sharing: devices work correctly more often when they are not sharing interrupts. That is simply a fact and I've seen too many problems related to IRQ sharing for anyone to convince me that it is not true. If the motherboard guy wants to blame it on crappy drivers for peripherals, fine. If peripheral makers want to blame it on crappy motherboards, fine. The fact is, for whatever reason and no matter what the nice documents defining PCI and AGP say, IRQ sharing, for whatever reason, sometimes does not work well with some devices. I think, then, that if you're building a PC, there's no reason not to try to avoid sharing IRQs. Certainly, your devices might all work fine even if they are on the same IRQ. But from my experience, your devices are MORE LIKELY to work if they are on separate interrupts. One final thought: I've got a PCI PowerMac from 1995 that I run Linux on. It has 32 interrupts, and all devices always get their own unique IRQ. I've never had any issues with PCI cards only working in certain slots, which certainly can't be said for most of my PCs. I suppose with things like APICs and ACPI, the x86 world is catching up in terms of interrupts, but it seems a little late in coming.  

Peter with most of the MB I've used there's a switch allowing the BIOS to be set to APIC or ACPI. Which is the better way to go with a modern OS like WinXP or Redhat9?  

It isn't APIC _or_ ACPI. You can have ACPI interface with or without having APIC interrupt controllers, and vice versa. Modern OSes are definitely better in controlling the system when the ACPI software interface is present. General performance is better when the operating system uses the APICs rather than the old PICs. Windows NT and its offsprings as well as Linux can, DOSy Windows flavors can't, but they don't care when APICs are present - they just don't kick the system into APIC mode and keep using the PICs.  

hatboy, the point is, as a card or mainboard designer, you can't do it electrically wrong. With the operating system then catching the actual interrupt trigger and despatching to the individual drivers, all that remains as a possible cause of interrupt related problems is the drivers. Now these then are still nothing to do with whether a certain IRQ vector is shared or not - it's rather whether a higher priority interrupt is holding the system for too long, sabotaging stuff on lower priority vectors. Random card shuffling stunts might or might not shift a card with a problematic driver onto a lower priority vector - that's all you do. Sure it does mask the symptoms w/o updating questionable drivers, but only until the next hardware item is added that reshuffles the routing, and only as long as the system is not using the APIC interrupt controllers. And it's not an IRQ sharing thing either - it's an IRQ prioritization thing, it's about whether the badly behaved drivers are on a high or low priority line. (On the PICs, the priority chain is 0-1-8-9-10-11-12-13-14-15-3-4-5-6-7, high to low.) When you're on the APICs, which any HT enabled P4 or other SMP system MUST have and use (and which also must be used by MS's standards on uniprocessor systems whose chipsets happen to have APIC hardware), there is no prioritization by the IRQ input line anymore at all. Card shuffling tricks simply don't work on these anymore at all. So you folks better learn the proper technique for building working systems: If a card misbehaves, check for driver updates, if none, return to sender and use someone else's.  

• Aug 2, 2003

I just want to say one more thing. The fact remains that if you have a problem and you change the IRQs and the problem goes away, then it appears to be an IRQ issue and it was solved. We do have control over this, but not the drivers without switching out equipment. This is what it boils down to whether an IRQ or driver problem. Peter, I do understand where you're coming from though now that you've explained it a little more. Thanks for the input!  

• Aug 3, 2003

You're welcome, and thanks for not playing foul anymore. The main point in why this all is rather pointless is: Practically all systems today run APIC mode, in which card shuffling does nothing and IRQs aren't routed anymore. You just HAVE to put up with using hardware whose drivers are well written. For an end user, the only way to put pressure on a vendor is to stop buying their stuff. For every piece of hardware out there known to have poorly written drivers (do I hear Creative?), there are well working alternatives.  

TRENDING THREADS

• Started by TheF34RChannel
• Jun 18, 2017
• Replies: 23K

• Started by DisEnchantment
• Sep 29, 2022
• Replies: 12K

• Started by Vattila
• Oct 6, 2019
• Replies: 13K
• Started by Tigerick
• Aug 22, 2022
• Replies: 8K

• Started by Eug
• Nov 10, 2020
• Replies: 7K

• Advertising
• Cookies Policies
• Term & Conditions

• This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register. By continuing to use this site, you are consenting to our use of cookies. Accept Learn more…

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Why is the keyboard assigned the specific IRQ of 1?

Why are specific IRQ values assigned to certain devices? For example, why is the system timer assigned the value of 0 and not 10?

• Poorly formed question. IRQ assignment is processor and board dependent. –  sawdust Aug 14, 2014 at 4:40

The IRQ level (IRQL) is also its priority; if two interrupt requests come in at the same time, the one with the lower level is handled first. That means if the system timer has IRQL 10, it would be relatively low priority and would be delayed by many other devices. Since the system timer is (or was, once upon a time) responsible for providing the system's ticks, it's essential that it not be interfered with

• This is also why no IRQ can be the same; two devices in conflict with same IRQ would cause a deadlock. –  Edward Aug 14, 2014 at 4:21
• 1 @Edward - "This is also why no IRQ can be the same" -- Incorrect, interrupts can be shared among multiple devices. Most interrupt controllers also llow interrupt lines to have the same priority. "two devices in conflict with same IRQ would cause a deadlock." Incorrect, there is no deadlock. Each interrupt line can be serviced in turn by the interrupt controller. –  sawdust Aug 14, 2014 at 4:45
• 1 "The IRQ level (IRQL) is also its priority" -- A modern interrupt controller allows assignment of a priority to each interrupt line. "the one with the lower level is handled first." -- There is no standard or convention for priority-to-numerical valuing. A higher priority can have larger numerical value, or in another system the higher priority could have a smaller numerical value. –  sawdust Aug 14, 2014 at 4:50

You must log in to answer this question.

• The Overflow Blog
• An open-source development paradigm
• Developers get by with a little help from AI: Stack Overflow Knows code...
• Featured on Meta
• Testing a new version of Stack Overflow Jobs
• What deliverables would you like to see out of a working group?

Hot Network Questions

• Do offensive abilities require the player to hit with an attack roll?
• A SF novel about a boy sold at a slave auction in a spaceport
• Can I copyright the recording of someone reading a work licensed under the terms of the Creative Commons Attribution 4.0 International License?
• Second floor thermostat, battery powered, does absolutely nothing and appears to not be connected to anything
• Denen in middle of a sentence
• How exactly does the JWST (James Webb Space Telescope) "see" light from so far away?
• Did Paul remain a Jew even after his conversion?
• What rises to the level of being a "a different spirit," per 2 Corinthians 11:4?
• Why would you build slow moving vehicles instead of faster ones?
• Can you color the 8x8 grid red and blue?
• Non-trivial solutions to homogenous system
• How many plot twists are too many plot twists?
• Is it bad style to write x^2, 2^\frac{1}{2} and 2^\sqrt{2}?
• What is a "rapid changes in gravitational force"
• They would/will have been married forty years come this June
• If someone is stranded in a transfer-only station after the last train has left, what happens?
• Is this safe to move?
• What are ordered pairs, and how does Kuratowski's definition make sense?
• How can I model curved ramp corner pieces for different angles?
• I just ordered a 26 by 1.95 tube but my tire is marked 26 by 2.10. Will the 1.95 tube fit the 2.10 tire?
• Break a word into vowels and consonants
• Why does a power inductor make a loud noise when first turned on then decay to a calmer "hum" later?
• How many Streifenkarte stripes are needed to get from Munich airport to the city centre?
• List of numbers in an arithmetic progression

Intel GA-G1975X PC Health Status, PCI 1 IRQ Assignment, PCI 2 IRQ Assignment, Case Opened, Vcore

Models: ga-g1975x.

PCI 1 IRQ Assignment

If the case is closed, "Case Opened" will show "No". If the case has been opened, "Case Opened" will show "Yes". If you want to reset "Case Opened" value, set "Reset Case Open Status" to Enabled then save BIOS setup and restart your system.

Current Voltage(V) Vcore / DDRV / +3.3V / +12V

Current CPU Temperature

Current CPU/POWER/SYSTEM FAN Speed (RPM)

• Forums New posts Search forums
• What's new New posts Latest activity
• Members Current visitors
• RTX 4060 vs RTX 3060 12GB GPU faceoff: New versus old mainstream GPUs compared

Change IRQ assignments

• Thread starter Guest
• Start date Aug 18, 2005
• Tags Configuration Nintendo Wireless Networking
• Windows Legacy
• Aug 18, 2005

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) I am not sure how to follow this tech support instruction: This article will have Bios and Windows settings that will help free up resourses on non used devices. Note after going through these steps you may need to "Reset the Configeration Data"(ECC Data). This will recycle the IRQs and free up the non used ones that might still being reserved by the motherboard. BIOS setup on my Micron Millennia TS doesn't explicitly list a reset configuration. How do I have the computer reassign the IRQ assignments? There is a Belkin 5-port USB 2 PCI card installed. The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. msinfo32 lists my IRQ assignments as: IRQ 0 System timer OK IRQ 1 Logitech PS/2 Keyboard OK IRQ 6 Standard floppy disk controller OK IRQ 8 System CMOS/real time clock OK IRQ 9 Microsoft ACPI-Compliant System OK IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK IRQ 12 Logitech-compatible Mouse PS/2 OK IRQ 13 Numeric data processor OK IRQ 14 Primary IDE Channel OK IRQ 15 Secondary IDE Channel OK IRQ 16 RADEON X700 Series OK IRQ 17 NEC PCI to USB Open Host Controller OK IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK IRQ 20 Intel(R) PRO/100 VE Network Connection OK IRQ 21 Standard Enhanced PCI to USB Host Controller OK IRQ 21 Creative SB Audigy 2 ZS (WDM) OK IRQ 22 OHCI Compliant IEEE 1394 Host Controller OK IRQ 23 NEC PCI to USB Open Host Controller OK IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK  

Distinguished

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) IRQ assignments are managed by device drivers, BIOS and OS configuration. The only way to manually assign an IRQ to a device on an XP computer running in ACPI mode(like yours), is to change to a "standard PC HAL". This can be done through device manager and will revert the pc back to the classic 15 IRQ lines. You still wont be allowed to manage resources in Windows, but you can force changes through BIOS. Brian P. A+, Network+, MCP "Arne" <[email protected]> wrote in message news:[email protected]... > I am not sure how to follow this tech support instruction: > > This article will have Bios and Windows settings that will help free up > resourses on non used devices. > Note after going through these steps you may need to "Reset the > Configeration Data"(ECC Data). This will recycle the IRQs and free up the > non used ones that might still being reserved by the motherboard. > > BIOS setup on my Micron Millennia TS doesn't explicitly list a reset > configuration. How do I have the computer reassign the IRQ assignments? > > There is a Belkin 5-port USB 2 PCI card installed. > > The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. > > msinfo32 lists my IRQ assignments as: > > IRQ 0 System timer OK > IRQ 1 Logitech PS/2 Keyboard OK > IRQ 6 Standard floppy disk controller OK > IRQ 8 System CMOS/real time clock OK > IRQ 9 Microsoft ACPI-Compliant System OK > IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK > IRQ 12 Logitech-compatible Mouse PS/2 OK > IRQ 13 Numeric data processor OK > IRQ 14 Primary IDE Channel OK > IRQ 15 Secondary IDE Channel OK > IRQ 16 RADEON X700 Series OK > IRQ 17 NEC PCI to USB Open Host Controller OK > IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK > IRQ 20 Intel(R) PRO/100 VE Network Connection OK > IRQ 21 Standard Enhanced PCI to USB Host Controller OK > IRQ 21 Creative SB Audigy 2 ZS (WDM) OK > IRQ 22 OHCI Compliant IEEE 1394 Host Controller OK > IRQ 23 NEC PCI to USB Open Host Controller OK > IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK >  

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) Not. I get the impression from the Creative Tech support that moving the PCI cards to different locations will change the IRQ assignments. Right now the cards are positioned because of where the external connectors are located. Is sharing an IRQ with the PCI to USB Host controller an inherently bad alignment? Arne "Brian" wrote: > IRQ assignments are managed by device drivers, BIOS and OS configuration. > The only way to manually assign an IRQ to a device on an XP computer running > in ACPI mode(like yours), is to change to a "standard PC HAL". This can be > done through device manager and will revert the pc back to the classic 15 > IRQ lines. You still wont be allowed to manage resources in Windows, but you > can force changes through BIOS. > > Brian P. > A+, Network+, MCP > > > > "Arne" <[email protected]> wrote in message > news:[email protected]... > > I am not sure how to follow this tech support instruction: > > > > This article will have Bios and Windows settings that will help free up > > resourses on non used devices. > > Note after going through these steps you may need to "Reset the > > Configeration Data"(ECC Data). This will recycle the IRQs and free up the > > non used ones that might still being reserved by the motherboard. > > > > BIOS setup on my Micron Millennia TS doesn't explicitly list a reset > > configuration. How do I have the computer reassign the IRQ assignments? > > > > There is a Belkin 5-port USB 2 PCI card installed. > > > > The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. > > > > msinfo32 lists my IRQ assignments as: > > > > IRQ 0 System timer OK > > IRQ 1 Logitech PS/2 Keyboard OK > > IRQ 6 Standard floppy disk controller OK > > IRQ 8 System CMOS/real time clock OK > > IRQ 9 Microsoft ACPI-Compliant System OK > > IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK > > IRQ 12 Logitech-compatible Mouse PS/2 OK > > IRQ 13 Numeric data processor OK > > IRQ 14 Primary IDE Channel OK > > IRQ 15 Secondary IDE Channel OK > > IRQ 16 RADEON X700 Series OK > > IRQ 17 NEC PCI to USB Open Host Controller OK > > IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK > > IRQ 20 Intel(R) PRO/100 VE Network Connection OK > > IRQ 21 Standard Enhanced PCI to USB Host Controller OK > > IRQ 21 Creative SB Audigy 2 ZS (WDM) OK > > IRQ 22 OHCI Compliant IEEE 1394 Host Controller OK > > IRQ 23 NEC PCI to USB Open Host Controller OK > > IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK > > > > >  

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) Changing slots may get it another IRQ line, but its not up to you. You cant manually assign or allolcate an IRQ to a certian PCI slot while your OS in using the ACPI HAL. Windows will just override the settings you have in the BIOS. If you want Windows to use the IRQ settings you define in BIOS, you must change your HAL to Standard PC. IRQ sharing usually works pretty well as long as you dont have to many devices using the same IRQ. If your having problems with devices on the same IRQ lines, (in your case, maybe audio dropouts)then yes you may need to consider updating your device drivers or changing the HAL so you can make changes. GL Brian P. A+, Network+, MCP "Arne" <[email protected]> wrote in message news:[email protected]... > Not. > > I get the impression from the Creative Tech support that moving the PCI > cards to different locations will change the IRQ assignments. Right now the > cards are positioned because of where the external connectors are located. > > Is sharing an IRQ with the PCI to USB Host controller an inherently bad > alignment? > > Arne > > "Brian" wrote: > > > IRQ assignments are managed by device drivers, BIOS and OS configuration. > > The only way to manually assign an IRQ to a device on an XP computer running > > in ACPI mode(like yours), is to change to a "standard PC HAL". This can be > > done through device manager and will revert the pc back to the classic 15 > > IRQ lines. You still wont be allowed to manage resources in Windows, but you > > can force changes through BIOS. > > > > Brian P. > > A+, Network+, MCP > > > > > > > > "Arne" <[email protected]> wrote in message > > news:[email protected]... > > > I am not sure how to follow this tech support instruction: > > > > > > This article will have Bios and Windows settings that will help free up > > > resourses on non used devices. > > > Note after going through these steps you may need to "Reset the > > > Configeration Data"(ECC Data). This will recycle the IRQs and free up the > > > non used ones that might still being reserved by the motherboard. > > > > > > BIOS setup on my Micron Millennia TS doesn't explicitly list a reset > > > configuration. How do I have the computer reassign the IRQ assignments? > > > > > > There is a Belkin 5-port USB 2 PCI card installed. > > > > > > The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. > > > > > > msinfo32 lists my IRQ assignments as: > > > > > > IRQ 0 System timer OK > > > IRQ 1 Logitech PS/2 Keyboard OK > > > IRQ 6 Standard floppy disk controller OK > > > IRQ 8 System CMOS/real time clock OK > > > IRQ 9 Microsoft ACPI-Compliant System OK > > > IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK > > > IRQ 12 Logitech-compatible Mouse PS/2 OK > > > IRQ 13 Numeric data processor OK > > > IRQ 14 Primary IDE Channel OK > > > IRQ 15 Secondary IDE Channel OK > > > IRQ 16 RADEON X700 Series OK > > > IRQ 17 NEC PCI to USB Open Host Controller OK > > > IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK > > > IRQ 20 Intel(R) PRO/100 VE Network Connection OK > > > IRQ 21 Standard Enhanced PCI to USB Host Controller OK > > > IRQ 21 Creative SB Audigy 2 ZS (WDM) OK > > > IRQ 22 OHCI Compliant IEEE 1394 Host Controller OK > > > IRQ 23 NEC PCI to USB Open Host Controller OK > > > IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK > > > > > > > > >  

• Aug 19, 2005

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) In article <[email protected]>, Arne says... > The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. > Why? If you're having issues with the Audigy, it's entirely to do with PCI latency, not the IRQ sharing. Download the PCI Latency Tool and set it to 64 for the Audigy. If you really insist on wanting to assign IRQs manually, I can help you with that but it is a royal PITA. -- Conor If Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music.  

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) No thanks, I am going to try removing the USB II PCI card and/ or Sound Blaster card moving to another PCI slot and see what happens. For the most part the sound card in functioning OK, with occassional drop outs. This problem became an issue when all of the Creative Programs disappeared from All Programs, even though all of the Sound Blaster files were present. If XP Home can sort out the problem by rebooting with a different selection of PCI slots, that is fine. Otherwise, the system runs well enough. Thank you, Arne "Conor" wrote: > In article <[email protected]>, Arne > says... > > > The goal is to have the Sound Blaster Audigy 2 ZS on an independent IRQ. > > > Why? If you're having issues with the Audigy, it's entirely to do with > PCI latency, not the IRQ sharing. Download the PCI Latency Tool and set > it to 64 for the Audigy. > > If you really insist on wanting to assign IRQs manually, I can help you > with that but it is a royal PITA. > > > > > -- > Conor > > If Pac-Man affected us as kids, we'd all be running around in darkened > rooms, munching magic pills and listening to repetitive electronic > music. >  

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) Arne Windows will dynamically assign IRQ's and has no problem with them being shared.. sometimes, switching slots can get over problems.. best not to use the slot nearest the AGP video card.. I have found Creative software to be less than perfect, and choose not to install any of the Creative stuff other than the drivers.. you may like to see if that works for you too.. -- Mike Hall MVP - Windows Shell/User "Arne" <[email protected]> wrote in message news:[email protected]... > No thanks, > > I am going to try removing the USB II PCI card and/ or Sound Blaster card > moving to another PCI slot and see what happens. > > For the most part the sound card in functioning OK, with occassional drop > outs. This problem became an issue when all of the Creative Programs > disappeared from All Programs, even though all of the Sound Blaster files > were present. > > If XP Home can sort out the problem by rebooting with a different > selection > of PCI slots, that is fine. Otherwise, the system runs well enough. > > Thank you, > > Arne > > "Conor" wrote: > >> In article <[email protected]>, Arne >> says... >> >> > The goal is to have the Sound Blaster Audigy 2 ZS on an independent >> > IRQ. >> > >> Why? If you're having issues with the Audigy, it's entirely to do with >> PCI latency, not the IRQ sharing. Download the PCI Latency Tool and set >> it to 64 for the Audigy. >> >> If you really insist on wanting to assign IRQs manually, I can help you >> with that but it is a royal PITA. >> >> >> >> >> -- >> Conor >> >> If Pac-Man affected us as kids, we'd all be running around in darkened >> rooms, munching magic pills and listening to repetitive electronic >> music. >>  

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) I found that it is possible to change IRQ assignments in BIOS Manual selection of IRQ in BIOS: Slot 3 IRQ11 (empty) Slot 4 IRQ 7 SB audigy 2 Slot 5 Belkin 5 port USB 2 (not configurable) Slots 1-4 are empty With only Slot 4 is set to IRQ 7 the SB was at IRQ 7 when I added IRQ 11 to Slot 3 the following assignments were made: IRQ 0 System timer OK IRQ 1 Logitech PS/2 Keyboard OK IRQ 6 Standard floppy disk controller OK IRQ 8 System CMOS/real time clock OK IRQ 9 Microsoft ACPI-Compliant System OK IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK IRQ 12 Logitech-compatible Mouse PS/2 OK IRQ 13 Numeric data processor OK IRQ 14 Primary IDE Channel OK IRQ 15 Secondary IDE Channel OK IRQ 16 RADEON X700 Series OK IRQ 17 Creative SB Audigy 2 ZS (WDM) OK IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK IRQ 20 Intel(R) PRO/100 VE Network Connection OK IRQ 21 OHCI Compliant IEEE 1394 Host Controller OK IRQ 21 NEC PCI to USB Open Host Controller OK IRQ 22 NEC PCI to USB Open Host Controller OK IRQ 23 Standard Enhanced PCI to USB Host Controller OK IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK I had to run the Creative diagnostics to "fix" the set up before the sound card would work. All in all, I think the time and effort was worthwhile. Arne "Mike Hall (MS-MVP)" wrote: > Arne > > Windows will dynamically assign IRQ's and has no problem with them being > shared.. sometimes, switching slots can get over problems.. best not to use > the slot nearest the AGP video card.. > > I have found Creative software to be less than perfect, and choose not to > install any of the Creative stuff other than the drivers.. you may like to > see if that works for you too.. > > > -- > Mike Hall > MVP - Windows Shell/User > > > "Arne" <[email protected]> wrote in message > news:[email protected]... > > No thanks, > > > > I am going to try removing the USB II PCI card and/ or Sound Blaster card > > moving to another PCI slot and see what happens. > > > > For the most part the sound card in functioning OK, with occassional drop > > outs. This problem became an issue when all of the Creative Programs > > disappeared from All Programs, even though all of the Sound Blaster files > > were present. > > > > If XP Home can sort out the problem by rebooting with a different > > selection > > of PCI slots, that is fine. Otherwise, the system runs well enough. > > > > Thank you, > > > > Arne > > > > "Conor" wrote: > > > >> In article <[email protected]>, Arne > >> says... > >> > >> > The goal is to have the Sound Blaster Audigy 2 ZS on an independent > >> > IRQ. > >> > > >> Why? If you're having issues with the Audigy, it's entirely to do with > >> PCI latency, not the IRQ sharing. Download the PCI Latency Tool and set > >> it to 64 for the Audigy. > >> > >> If you really insist on wanting to assign IRQs manually, I can help you > >> with that but it is a royal PITA. > >> > >> > >> > >> > >> -- > >> Conor > >> > >> If Pac-Man affected us as kids, we'd all be running around in darkened > >> rooms, munching magic pills and listening to repetitive electronic > >> music. > >> > > >  

• Aug 31, 2005

Archived from groups: microsoft.public.windowsxp.help_and_support ( More info? ) Can you walk me through how you did this BIOS change. I have concluded I need to do this - Device Manager does not give me the options .. I have resource conflicts when reisntalling a Sitecom USB 2 card which conflicts with 2 other devices. I am only using 1 of 3 PCE slots - the conflicting devices are a graphics driver and numeric data processor - both system devioces so not physically removable/swappable - and have tried the USB card in all available slots with no improvement. The conflict results in Code 10 and Code 12 errors. Any helpful suggestions appreciated jim_50 "Arne" wrote: > I found that it is possible to change IRQ assignments in BIOS > > Manual selection of IRQ in BIOS: > > Slot 3 IRQ11 (empty) > Slot 4 IRQ 7 SB audigy 2 > Slot 5 Belkin 5 port USB 2 (not configurable) > > Slots 1-4 are empty > > With only Slot 4 is set to IRQ 7 the SB was at IRQ 7 > when I added IRQ 11 to Slot 3 the following assignments were made: > > IRQ 0 System timer OK > IRQ 1 Logitech PS/2 Keyboard OK > IRQ 6 Standard floppy disk controller OK > IRQ 8 System CMOS/real time clock OK > IRQ 9 Microsoft ACPI-Compliant System OK > IRQ 10 Intel(R) 82801BA/BAM SMBus Controller - 2443 OK > IRQ 12 Logitech-compatible Mouse PS/2 OK > IRQ 13 Numeric data processor OK > IRQ 14 Primary IDE Channel OK > IRQ 15 Secondary IDE Channel OK > IRQ 16 RADEON X700 Series OK > IRQ 17 Creative SB Audigy 2 ZS (WDM) OK > IRQ 19 Intel(R) 82801BA/BAM USB Universal Host Controller - 2442 OK > IRQ 20 Intel(R) PRO/100 VE Network Connection OK > IRQ 21 OHCI Compliant IEEE 1394 Host Controller OK > IRQ 21 NEC PCI to USB Open Host Controller OK > IRQ 22 NEC PCI to USB Open Host Controller OK > IRQ 23 Standard Enhanced PCI to USB Host Controller OK > IRQ 23 Intel(R) 82801BA/BAM USB Universal Host Controller - 2444 OK > > I had to run the Creative diagnostics to "fix" the set up before the sound > card would work. > > All in all, I think the time and effort was worthwhile. > > Arne > > "Mike Hall (MS-MVP)" wrote: > > > Arne > > > > Windows will dynamically assign IRQ's and has no problem with them being > > shared.. sometimes, switching slots can get over problems.. best not to use > > the slot nearest the AGP video card.. > > > > I have found Creative software to be less than perfect, and choose not to > > install any of the Creative stuff other than the drivers.. you may like to > > see if that works for you too.. > > > > > > -- > > Mike Hall > > MVP - Windows Shell/User > > > > > > "Arne" <[email protected]> wrote in message > > news:[email protected]... > > > No thanks, > > > > > > I am going to try removing the USB II PCI card and/ or Sound Blaster card > > > moving to another PCI slot and see what happens. > > > > > > For the most part the sound card in functioning OK, with occassional drop > > > outs. This problem became an issue when all of the Creative Programs > > > disappeared from All Programs, even though all of the Sound Blaster files > > > were present. > > > > > > If XP Home can sort out the problem by rebooting with a different > > > selection > > > of PCI slots, that is fine. Otherwise, the system runs well enough. > > > > > > Thank you, > > > > > > Arne > > > > > > "Conor" wrote: > > > > > >> In article <[email protected]>, Arne > > >> says... > > >> > > >> > The goal is to have the Sound Blaster Audigy 2 ZS on an independent > > >> > IRQ. > > >> > > > >> Why? If you're having issues with the Audigy, it's entirely to do with > > >> PCI latency, not the IRQ sharing. Download the PCI Latency Tool and set > > >> it to 64 for the Audigy. > > >> > > >> If you really insist on wanting to assign IRQs manually, I can help you > > >> with that but it is a royal PITA. > > >> > > >> > > >> > > >> > > >> -- > > >> Conor > > >> > > >> If Pac-Man affected us as kids, we'd all be running around in darkened > > >> rooms, munching magic pills and listening to repetitive electronic > > >> music. > > >> > > > > > >  

TRENDING THREADS

• Started by jnjnilson6
• Tuesday at 12:54 PM
• Replies: 55

• Started by Admin
• Tuesday at 1:50 PM
• Replies: 71
• May 9, 2024
• Replies: 80
• Wednesday at 7:35 AM
• Replies: 21
• Wednesday at 8:30 AM
• Replies: 33
• Started by Gokhannn
• Thursday at 1:36 PM
• Replies: 35

• Started by tecmo34
• Apr 30, 2011
• Replies: 5K

Latest posts

• Latest: SkyNetRising
• 9 minutes ago

• Latest: kerberos_20
• Latest: ragez0r
• 10 minutes ago
• Latest: Ryuka
• 14 minutes ago

• Latest: xTiddi
• 16 minutes ago

• Latest: Stabilio
• 17 minutes ago
• 24 minutes ago

Moderators online

Share this page

• Advertising
• Cookies Policies
• Term & Conditions

Select Your Language

• Single-page

Language and Page Formatting Options

Red hat training.

A Red Hat training course is available for Red Hat Enterprise Linux

4.3. Interrupts and IRQ Tuning

Quick links.

• Subscriptions
• Support Cases
• Customer Service
• Product Documentation
• Contact Customer Portal
• Customer Portal FAQ
• Log-in Assistance
• Trust Red Hat
• Browser Support Policy
• Accessibility
• Awards and Recognition

Related Sites

• developers.redhat.com
• connect.redhat.com
• cloud.redhat.com

Systems Status

• Red Hat Subscription Value
• About Red Hat
• Red Hat Jobs

Red Hat legal and privacy links

• Contact Red Hat
• Red Hat Blog
• Diversity, equity, and inclusion
• Cool Stuff Store
• Red Hat Summit
• Privacy statement
• Terms of use
• All policies and guidelines
• Digital accessibility

Log in or Sign up

You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser .

• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Motherboards Help me understand IRQ assignments on Asus motherboard

Discussion in ' Hardware ' started by Chicken76 , 3 Oct 2012 .

Chicken76 Minimodder

Board in question is Asus P8Z77-V If you look in the manual at page 2-13 there is a table called IRQ assignments for this motherboard What I don't understand is what are the A B C ... H columns?  

Guest-16 Guest

I'm not sure either but why do you need to assign IRQs? EDIT: Oh I think they can be assigned to any IRQ, but all under a particular column will be shared whatever the number.  

I don't need to assign IRQs manually. I just need to populate at least 3 PCI-E slots and also use (some of) the USB ports and the integrated NIC. And not having shared interrupts will be a big plus for me. I also initially considered what you said, but for some scenarios it just doesn't make sense. Take column C for example, you'd think no slots are populated, only ASMedia USB controller is turned on, and it will have it's interrupt shared, right? But with whom? Or column A, you have the interrupt of your discrete video card shared with the third PCI-E 16x slot (meh...), a PCI slot and also two USB controllers?! So if you have USB mouse and keyboard and a USB or PCI sound card/amp then you can kiss smoothness goodbye in (for example) any demanding 3D game? I feel we're not interpreting the table correctly, or some information was left out of the manual somehow.  

Phalanx Needs more dragons and stuff.

IRQ interrupts are best left to the OS, trust me. You do NOT want to go prodding, unless you fancy going back to the age of Windows 3.11-95.  

faugusztin I *am* the guy with two left hands

Chicken76 said: ↑ I also initially considered what you said, but for some scenarios it just doesn't make sense. Take column C for example, you'd think no slots are populated, only ASMedia USB controller is turned on, and it will have it's interrupt shared, right? But with whom? Click to expand...

Chicken76 said: ↑ I don't need to assign IRQs manually. I just need to populate at least 3 PCI-E slots and also use (some of) the USB ports and the integrated NIC. And not having shared interrupts will be a big plus for me. I also initially considered what you said, but for some scenarios it just doesn't make sense. Take column C for example, you'd think no slots are populated, only ASMedia USB controller is turned on, and it will have it's interrupt shared, right? But with whom? Or column A, you have the interrupt of your discrete video card shared with the third PCI-E 16x slot (meh...), a PCI slot and also two USB controllers?! So if you have USB mouse and keyboard and a USB or PCI sound card/amp then you can kiss smoothness goodbye in (for example) any demanding 3D game? I feel we're not interpreting the table correctly, or some information was left out of the manual somehow. Click to expand...

Alright, thanks guys. Have some rep.  

Share This Page

• No, create an account now.
• Yes, my password is:
• Forgot your password?

• Search titles only

Separate names with a comma.

• Search this thread only
• Display results as threads

Useful Searches

• Recent Posts

irqbalance - distribute hardware interrupts across processors on a multiprocessor system

DESCRIPTION

The purpose of irqbalance is to distribute hardware interrupts across processors on a multiprocessor system in order to increase performance.

The default value for deepestcache is 2.

ENVIRONMENT VARIABLES

irqbalance is able to communicate via socket and return it's current assignment tree and setup, as well as set new settings based on sent values. Socket is abstract, with a name in form of irqbalance<PID>.sock , where <PID> is the process ID of irqbalance instance to communicate with. Possible values to send:

irqbalance checks SCM_CREDENTIALS of sender (only root user is allowed to interact). Based on chosen tools, ancillary message with credentials needs to be sent with request.

https://github.com/Irqbalance/irqbalance

Contribute to the Windows forum! Click  here  to learn more  💡

May 10, 2024

Contribute to the Windows forum!

Click  here  to learn more  💡

Windows 10 Forum Top Contributors: Ramesh Srinivasan  -  neilpzz  -  Volume Z  -  franco d'esaro  -  _AW_   ✅

Windows 10 Forum Top Contributors:

Ramesh Srinivasan  -  neilpzz  -  Volume Z  -  franco d'esaro  -  _AW_   ✅

• Search the community and support articles
• Search Community member

Ask a new question

IRQ Conflicts between ISA and PCI Devices?

I was having some DPC latency issues with my NVIDIA GeForce GTX 1070 Ti Drivers that were causing my mouse to stutter (particularly when mousing over browser links or between windows)

While troubleshooting I noticed that the PCI drivers for my 1070 and my Sound are using the same IRQ channel as the ISA "Microsoft ACPI-Compliant System" - screenshot at the end.

Are these IRQ conflicts between PCI and ISA a possible cause of my mouse stutter or is this not an issue? I ask this because I can't seem to change the IRQ assignment of anything?

I've tried or failed to:

1) Change the PCI IRQ channels in windows, but "Use automatic settings" is grey and I can't uncheck.

2) Change PCI IRQ assignment in my BIOS, but it seems my mobo doesn't support this & I can't figure this out anyways

3) Can't change the PCIE slot my 1070 uses because there is only 1 slot on my mobo. The HD audio controller is built into the mobo.

Report abuse

Reported content has been submitted​

Replies (1) 

• Microsoft Agent |

An outdated mouse driver is one of the possible causes of the latency. We'd like to ask few questions so we can isolate your concern properly. Kindly answer the following:

• What's the current build of your computer?
• Have you tried to use a different mouse to see if the same issue persists?
• Did you try to update your chipset driver?

Meanwhile, kindly boot your computer into safe mode with networking and let's see if there will be a latency whenever you use the mouse. To do this, follow these steps:

• Restart your PC. When you get to the sign-in screen, hold the   Shift   key down while you select   Power     >   Restart .
• After your PC restarts to the   Choose an option   screen, select   Troubleshoot   >   Advanced options   >   Startup Settings   >   Restart .
• After your PC restarts, you'll see a list of options. Select   4   or   F4   to start your PC in   Safe Mode . Or if you'll need to use the Internet, select   5   or   F5   for   Safe Mode   with   Networking .

Was this reply helpful? Yes No

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

Thanks for your feedback.

Question Info

• Devices and drivers
• Norsk Bokmål
• Ελληνικά
• Русский
• עברית
• العربية
• ไทย
• 한국어
• 中文(简体)
• 中文(繁體)
• 日本語

The Place to Start for Operating System Developers

Skip to content

• Board index ‹ Operating System Development ‹ OS Development
• Change font size

Question about PCI IRQ assignment

Moderators: AJ, 01000101, carbonBased, Candy, pcmattman, JAAman, Octocontrabass, klange, sortie, kmcguire, thepowersgang, chase, Combuster, Owen

Re: Question about PCI IRQ assignment

mohammedisam wrote: So I am working with ATA/ATAPI and everything goes right through PIO mode. I want to switch to DMA mode as I recently implemented multiprocessing and I can't go on with PIO as such. I understand the ATA uses IRQs 14&15 by default. But when enumerating the PCI space, I read the config space for the specified disk and try to read the Interrupt Line (byte at offset 0x3c of header 0x00) all I get is 0. Other devices (like Power management and VGA) give plausible results (like IRQ 9). Should I reprogram the IRQ line of each disk on startup to use IRQ 14/15 or what is the approach to get the right values? P.S.: I get the same results under VirtualBox, Bochs, and QEmu. P.S.2: Even though I get 0 as I read the interrupt line byte, still the disks fire IRQs 14 (HDD connected as primary master) and 15 (CDROM connected as secondary master).

Return to OS Development

Who is online

Users browsing this forum: Google [Bot] and 39 guests

• Board index
• All times are UTC

xen/pci: remove redundant assignment to variable irq

Commit message.