_DSD (Device Specific Data) Implementation Guide

 

 

July 2014

 

Revision 1.0

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Document Number: XXXXXX

 

 

 


Contents

1................... Introduction. 6

1.1 Terms. 6

1.2 Conventions used in this document 6

1.2.1 Typographic conventions. 6

2................... General Recommendations. 8

2.1 _DSD and _DSM.. 8

2.2 General _DSD Definition Template. 8

3................... Well Known _DSD UUIDs and Data Structure Formats. 9

3.1 Device Properties UUID. 9

 

 

Revision history

 

Revision
Number

Description

Revision
Date

<1.0>

First revision

July 16, 2014

 


 


1                      Introduction

This document gives recommendations on the use of the _DSD (Device Specific Data) ACPI device configuration object. It is intended for firmware and software engineers implementing _DSD or designing software that will use information supplied by it.

The _DSD, as defined by the ACPI Specification, returns a Package the first and every odd element of which is a Universal Unique Identifier (UUID) and every even element of which is a Package (Data Structure), where each of the UUIDs determines the format of the Data Structure immediately following it. The well-known UUIDs to use in the _DSD output and the Data Structure formats associated with them are also specified in this document.

1.1     Terms

The following terms are used throughout this document to describe varying aspects of input localization:

ACPI

Advanced Configuration and Power Interface specification.

Device

Hardware component or set of interrelated hardware registers.

Device ID

Plug and Play ID or ACPI ID of a device.

GUID

Globally Unique Identifier. A 128-bit value used to uniquely name entities. A unique GUID can be generated by an individual without the help of a centralized authority. This allows the generation of names that will never conflict, even among multiple, unrelated parties.

UUID

Universal Unique Identifier, GUID.

1.2     Conventions used in this document

1.2.1              Typographic conventions

This document uses the typographic and illustrative conventions described below:

Plain text

The normal text typeface is used for the vast majority of the descriptive text in a specification.

BOLD Monospace

Computer code, example code segments, and all prototype code segments use a BOLD Monospace typeface with a dark red color. These code listings normally appear in one or more separate paragraphs, though words or segments can also be embedded in a normal text paragraph.

 


2                      General Recommendations

2.1     _DSD and _DSM

Although in principle _DSM (Device Specific Method) may be used to implement the functionality provided by _DSD, it is not recommended to do so. Since _DSD is better suited for providing device configuration data, it should be used for this purpose where applicable. However, there are situations in which using _DSM instead of it needs to be considered. Generally, all situations in which it would be necessary to implement _DSD as a method for technical reasons fall into this category, but in particular _DSD should not write into device registers in addition to returning the data. In addition to that, _DSD must return the same data every time it is evaluated, so if that cannot be guaranteed, _DSM has to be used instead of it.

2.2     General _DSD Definition Template

Wherever possible, it is recommended to implement _DSD as a Name, as opposed to a Method, so as to avoid programmatic errors and computational overhead associated with the execution of AML code. In that case the definition of _DSD should follow the common template below.

Name (_DSD, Package () {

ToUUID("UUID1"),

Package () {

...

},

ToUUID("UUID2"),

Package () {

...

},

...

ToUUID("UUIDn"),

Package () {

...

}

})

3                      Well Known _DSD UUIDs and Data Structure Formats

3.1     Device Properties UUID

http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf