Geräteverwaltungsnamespaceobjekte

Die ACPI 5.0-Spezifikation definiert mehrere Typen von Namespaceobjekten, die zum Verwalten von Geräten verwendet werden können. Geräteidentifikationsobjekte enthalten beispielsweise Identifikationsinformationen für Geräte, die eine Verbindung mit Bussen herstellen, z. B. I2C, die keine Hardwareaufzählung untergeordneter Geräte unterstützen. Andere Typen von Namespaceobjekten können Systemressourcen angeben, Geräteabhängigkeiten beschreiben und angeben, welche Geräte deaktiviert werden können.

Geräteidentifikation in Windows

Windows Plug & Play sucht und lädt Gerätetreiber basierend auf einem Gerätebezeichner, der vom Enumerator des Geräts bereitgestellt wird. Enumeratoren sind Bustreiber, die wissen, wie Identifikationsinformationen aus dem Gerät extrahiert werden. Einige Busse (z. B. PCI, SD und USB) verfügen über hardwaredefinierte Mechanismen für diese Extraktion. Für Busse, die dies nicht gibt (z. B. der Prozessorbus oder ein einfacher Peripheriebus), definiert ACPI Identifikationsobjekte im Namespace.

Der Windows ACPI-Treiber Acpi.sys sammelt die in diesen Objekten gefundenen Werte zu verschiedenen Gerätebezeichnerzeichenfolgen, die ein Gerät je nach Den Anforderungen des Treibers spezifisch oder generisch identifizieren können. Einige der Zeichenfolgenmuster, die erstellt wurden, um ACPI-enumerierte Geräte zu identifizieren, sind:

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

Sie können die Gerätebezeichner anzeigen, die Windows für Ihr Gerät erstellt, indem Sie Geräte-Manager öffnen und die Eigenschaften Hardware-IDs und Kompatible IDs des aufgezählten Geräts überprüfen. Jede dieser Zeichenfolgen kann in einer INF-Datei angegeben werden, um den Treiber zu identifizieren, der für das Gerät geladen werden soll. Die Reihenfolge des INF-Abgleichs ist vom spezifischsten Hardwarebezeichner (am meisten bevorzugter Treiber) bis zum geringsten spezifischen Bezeichner (am wenigsten bevorzugter Treiber), sodass Treiber, die mehr über die spezifischen Features des Geräts wissen, die weniger spezifisch sind (und daher nur eine Teilmenge der Gerätefeatures unterstützen) ersetzen können.

Gerätebezeichner sollten nur für den INF-Abgleich verwendet werden und sollten nie vom Gerätetreiber analysiert oder verarbeitet werden. Wenn der Gerätetreiber die spezifische Hardware identifizieren muss, für die er geladen wurde, ist die empfohlene Methode, dass die INF-Datei zur Installationszeit die entsprechenden Registrierungsschlüssel festgelegt hat. Der Treiber kann dann während der Initialisierung auf diese Schlüssel zugreifen, um die erforderlichen Informationen abzurufen.

Geräteidentifikation in ACPI

Hardware-ID (_HID)

Die Mindestanforderung zum Identifizieren eines Geräts in ACPI ist das Hardware-ID-Objekt (_HID). _HID gibt eine Zeichenfolge mit dem Format "ABC[D]xxxx" zurück, wobei "ABC[D]" eine 3-stellige oder 4-stellige Zeichenfolge ist, die den Hersteller des Geräts identifiziert (die "Anbieter-ID"), und xxxx eine hexadezimale Zahl ist, die das von diesem Anbieter hergestellte bestimmte Gerät identifiziert (die "Geräte-ID"). Anbieter-IDs müssen branchenweit eindeutig sein. Microsoft weist diese Zeichenfolgen zu, um sicherzustellen, dass sie eindeutig sind. Anbieter-IDs können über Plug & Play-ID – PNPID-Anforderung abgerufen werden.

ACPI 5.0 unterstützt auch die Verwendung pci-zugewiesener Anbieter-IDs in _HID und anderen Identifikationsobjekten, sodass Sie möglicherweise keine Anbieter-ID von Microsoft abrufen müssen. Weitere Informationen zu Hardwareidentifizierungsanforderungen finden Sie in Abschnitt 6.1.5, "_HID (Hardware-ID)" der ACPI 5.0-Spezifikation.

Kompatible ID (_CID)

Microsoft hat die Anbieter-ID "PNP" für Geräte reserviert, die mit den mit Windows ausgelieferten Posteingangstreibern kompatibel sind. Windows definiert eine Reihe von Geräte-IDs für die Verwendung mit dieser Anbieter-ID, die zum Laden des von Windows bereitgestellten Treibers für ein Gerät verwendet werden können. Ein separates Objekt, das Compatible ID -Objekt (_CID), wird verwendet, um diese Bezeichner zurückzugeben. Windows bevorzugt immer Hardware-IDs (die von _HID zurückgegeben werden) gegenüber kompatiblen IDs (von _CID zurückgegeben) bei INF-Abgleich und Treiberauswahl. Mit dieser Einstellung kann der von Windows bereitgestellte Treiber als Standardtreiber behandelt werden, wenn kein vom Hersteller bereitgestellter gerätespezifischer Treiber verfügbar ist. Die kompatiblen IDs in der folgenden Tabelle werden für die Verwendung mit SoC-Plattformen neu erstellt.

Subsystem-ID (_SUB), Hardwarerevision (_HRV) und Klasse (_CLS)

ACPI 5.0 definiert die _SUB, _HRV und _CLS-Objekte, die zusammen mit dem _HID verwendet werden können, um Bezeichner zu erstellen, die eine bestimmte Version, Integration oder Hardwarerevision eines Geräts eindeutiger identifizieren oder die Zugehörigkeit zu einer PCI-definierten Geräteklasse angeben. Diese Objekte sind in der Regel optional, sind aber möglicherweise von bestimmten Geräteklassen in Windows erforderlich. Weitere Informationen zu diesen Objekten finden Sie in Abschnitt 6.1, "Geräteidentifikationsobjekte" der ACPI 5.0-Spezifikation.

Aus Gründen der Servicefähigkeit ist für das Windows Hardware Certification Kit (HCK) erforderlich, dass Geräte-IDs auf OEM-Systemen "vierteilige" IDs sind. Die vier Teile sind die Anbieter-ID, die Geräte-ID, die OEM-ID (Subsystem vendor) und die OEM-Geräte-ID (Subsystem). Daher ist das Subsystem-ID-Objekt (_SUB) für OEM-Plattformen erforderlich.

Device-Specific-Methode (_DSM)

Die _DSM-Methode wird in Abschnitt 9.14.1, "_DSM (gerätespezifische Methode)" der ACPI 5.0-Spezifikation definiert. Diese Methode stellt individuelle, gerätespezifische Daten und Steuerungsfunktionen bereit, die von einem Gerätetreiber aufgerufen werden können, ohne mit anderen solchen gerätespezifischen Methoden in Konflikt zu stehen. Die _DSM für ein bestimmtes Gerät oder eine bestimmte Geräteklasse definiert eine UUID (GUID), die garantiert nicht mit anderen UUIDs kollidiert. Für jede UUID gibt es eine Reihe von definierten Funktionen, die die _DSM-Methode implementieren kann, um Daten bereitzustellen oder Steuerfunktionen für den Treiber auszuführen. Klassenspezifische Daten und Datenformate werden in separaten geräteklassenspezifischen Spezifikationen bereitgestellt und auch in ACPI Device-Specific Methods erläutert.

Adresse (_ADR) und eindeutige ID (_UID)

Es gibt drei zusätzliche Anforderungen für die Geräteidentifikation:

• Für Geräte, die eine Verbindung mit einem hardwarebasierten übergeordneten Bus herstellen (z. B. SDIO, USB HSIC), die jedoch plattformspezifische Features oder Steuerelemente (z. B. Seitenband-Netz oder Wake-Interrupt) aufweisen, wird der _HID nicht verwendet. Stattdessen wird der Gerätebezeichner vom übergeordneten Bustreiber erstellt (wie zuvor erläutert). In diesem Fall muss sich das Address Object (_ADR) jedoch im ACPI-Namespace des Geräts befinden. Dieses Objekt ermöglicht es dem Betriebssystem, das bus-enumerierte Gerät seinen ACPI-beschriebenen Features oder Steuerelementen zuzuordnen.
• Auf Plattformen, auf denen mehrere Instanzen eines bestimmten IP-Blocks verwendet werden, sodass jeder Block über die gleichen Geräteidentifikationsobjekte verfügt, ist das Objekt Eindeutiger Bezeichner (_UID) erforderlich, damit das Betriebssystem zwischen Blöcken unterscheiden kann.
• Keine zwei Geräte in einem bestimmten Namespacebereich können denselben Namen haben.

Gerätekonfigurationsobjekte

Für jedes im Namespace identifizierte Gerät müssen die systeminternen Ressourcen (Speicheradressen, Interrupts usw.), die vom Gerät genutzt werden, auch vom Objekt Current Resource Settings (_CRS) gemeldet werden. Berichte über mehrere mögliche Ressourcenkonfigurationen (_PRS) und Steuerelemente zum Ändern der Ressourcenkonfiguration eines Geräts (_SRS) werden unterstützt, aber optional.

Neu für SoC-Plattformen sind GPIO- und SPB-Ressourcen (Simple Peripheral Bus), die ein Gerät nutzen kann. Weitere Informationen finden Sie unter Universell E/A (GPIO) und Simple Peripheral Bus (SPB).

Ebenfalls neu für SoC-Plattformen ist ein universeller fixer DMA-Deskriptor. Der FixedDMA-Deskriptor unterstützt die Freigabe von DMA-Controllerhardware durch eine Reihe von Systemgeräten. Die einem bestimmten Systemgerät statisch zugeordneten DMA-Ressourcen (Anforderungszeilen- und Kanalregister) werden im FixedDMA-Deskriptor aufgeführt. Weitere Informationen finden Sie in Abschnitt 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)" der ACPI 5.0-Spezifikation.

Gerätestatusänderungen

ACPI-enumerierte Geräte können aus verschiedenen Gründen deaktiviert oder entfernt werden. Das Status -Objekt (_STA) wird bereitgestellt, damit solche Statusänderungen an das Betriebssystem übermittelt werden können. Eine Beschreibung der _STA finden Sie in Abschnitt 6.3.7 der ACPI 5.0-Spezifikation. Windows verwendet _STA, um zu bestimmen, ob das Gerät aufgelistet, als deaktiviert oder für den Benutzer nicht sichtbar angezeigt werden soll. Dieses Steuerelement in der Firmware ist für viele Anwendungen nützlich, einschließlich Docking und USB OTG-Host-zu-Funktion-Umschaltung.

Darüber hinaus bietet ACPI einen Benachrichtigungsmechanismus, den ASL verwenden kann, um Treiber über Ereignisse auf der Plattform zu benachrichtigen, z. B. ein Gerät, das als Teil eines Docks entfernt wird. Wenn sich der Status eines ACPI-Geräts ändert, muss die Firmware eine Benachrichtigung zur "Geräteprüfung" oder "Busüberprüfung" ausführen, damit Windows das Gerät neu aufzählt und seine _STA neu auswertet. Informationen zu ACPI-Benachrichtigungen finden Sie in Abschnitt 5.6.6, "Geräteobjektbenachrichtigungen" der ACPI 5.0-Spezifikation.

Aktivieren/Deaktivieren

Im Rahmen von Windows Plug & Play müssen Treiber vom Benutzer oder vom System dynamisch aktiviert und deaktiviert werden können (z. B. zum Aktualisieren eines Treibers).

On-SoC-Geräte sind in den SoC-Chip integriert und können nicht entfernt werden. Treiber für die meisten SoC-Geräte können von den Anforderungen zum Aktivieren und Deaktivieren ausgenommen werden. Für treiber, die nicht ausgenommen sind, gibt es Treiberschnittstellen, die angeben, dass der Treiber das geordnete Entfernen unterstützt. Weitere Informationen finden Sie im Dokument "Reduzieren der PNP-Anforderungen für SoC-Treiber" auf der Microsoft Connect-Website.

Wenn ein Treiber das geordnete Entfernen unterstützt und die Gerätehardware deaktiviert werden kann (d. h. das Gerät kann so konfiguriert werden, dass der Zugriff auf die zugewiesenen Ressourcen beendet wird), kann der ACPI-Namespaceknoten für das Gerät das Objekt Disable (_DIS) enthalten. Diese Methode wird vom Betriebssystem ausgewertet, wenn der Treiber entfernt wird. Für die Verwendung von _DIS gelten die folgenden zusätzlichen Anforderungen:

• _STA müssen das Bit "Aktiviert und Decodierung seiner Ressourcen" löschen, wenn das Gerät deaktiviert ist.
• Das Gerät muss das objekt Set Resource Settings (_SRS) bereitstellen, um die Gerätehardware erneut zu aktivieren und das oben genannte Bit in _STA festzulegen.

Weitere Informationen finden Sie in den Abschnitten 6.2.3 (_DIS), 6.2.15 (_SRS) und 6.3.7 (_STA) der ACPI 5.0-Spezifikation.

Geräteabhängigkeiten

In der Regel gibt es Hardwareabhängigkeiten zwischen Geräten auf einer bestimmten Plattform. Windows erfordert, dass alle derartigen Abhängigkeiten beschrieben werden, damit sichergestellt werden kann, dass alle Geräte ordnungsgemäß funktionieren, wenn sich die Dinge dynamisch im System ändern (Gerätestrom wird entfernt, Treiber werden beendet und gestartet usw.). In ACPI werden Abhängigkeiten zwischen Geräten wie folgt beschrieben:

1. Namespacehierarchie. Jedes Gerät, das ein untergeordnetes Gerät ist (das im Namespace eines anderen Geräts als Gerät aufgeführt wird) ist vom übergeordneten Gerät abhängig. Beispielsweise ist ein USB-HSIC-Gerät von dem Port (übergeordneten) und Controller (Großeltern) abhängig, mit dem es verbunden ist. Ebenso ist ein GPU-Gerät, das im Namespace eines MMU-Geräts (System Memory Management Unit) aufgeführt ist, vom MMU-Gerät abhängig.

2. Ressourcenverbindungen. Geräte, die mit GPIO- oder SPB-Controllern verbunden sind, sind von diesen Controllern abhängig. Diese Art von Abhängigkeit wird durch die Aufnahme von Verbindungsressourcen in die _CRS des Geräts beschrieben.

3. OpRegion-Abhängigkeiten. Bei ASL-Steuerungsmethoden, die OpRegions zum Ausführen von E/A verwenden, sind Abhängigkeiten dem Betriebssystem nicht implizit bekannt, da sie nur während der Auswertung der Steuerungsmethoden bestimmt werden. Dieses Problem gilt für GeneralPurposeIO und GenericSerialBus OpRegions, in denen Plug & Play Treiber Zugriff auf die Region gewähren. Um dieses Problem zu beheben, definiert ACPI das OpRegion Dependency-Objekt (_DEP). _DEP sollte in jedem Gerätenamespace verwendet werden, in dem von einer Steuerungsmethode auf eine OpRegion-Ressource (HW-Ressource) verwiesen wird, und weder 1 noch 2 gilt bereits für die Verbindungsressource von OpRegion, auf die verwiesen wird. Weitere Informationen finden Sie in Abschnitt 6.5.8, "_DEP (Operation Region Dependencies)" der ACPI 5.0-Spezifikation.

Es kann auch Softwareabhängigkeiten zwischen Gerätetreibern geben. Diese Abhängigkeiten müssen ebenfalls beschrieben werden.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Informationen zu Abhängigkeiten der Treiberladereihenfolge finden Sie unter Angeben der Treiberladereihenfolge.

• Power-Relations-Abhängigkeiten finden Sie unter:

  • IoInvalidateDeviceRelations (Um das Einrichten von Energiebeziehungen auszulösen, rufen Sie die IoInvalidateDeviceRelations-Routine mit dem DEVICE_RELATION_TYPE Enumerationswert PowerRelations auf.)

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • Auflisten der Geräte in einem Bus

  • Dynamische Enumeration