Geräteverwaltungsnamespaceobjekte

Die ACPI 5.0-Spezifikation definiert mehrere Typen von Namespaceobjekten, die zum Verwalten von Geräten verwendet werden können. Beispielsweise enthalten Geräteidentifikationsobjekte Identifikationsinformationen für Geräte, die mit Bussen wie I2C verbunden sind, 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 and Play findet und lädt Gerätetreiber basierend auf einem Gerätebezeichner, der vom Enumerator des Geräts bereitgestellt wird. Enumeratoren sind Busfahrer, die wissen, wie Identifikationsinformationen vom Gerät extrahiert werden. Einige Busse (z. B. PCI, SD und USB) verfügen über hardwaredefinierte Mechanismen, um diese Extraktion zu erledigen. Bei Bussen, die nicht (z. B. der Prozessorbus oder ein einfacher Peripheriebus), definiert ACPI Identifikationsobjekte im Namespace.

Der Windows ACPI-Treiber, Acpi.sys, fasst die in diesen Objekten gefundenen Werte in verschiedenen Gerätebezeichnerzeichenfolgen zusammen, die je nach den Anforderungen des Treibers ein Gerät spezifisch oder generisch identifizieren können. Einige der Zeichenfolgenmuster, die zum Identifizieren von ACPI-aufgezählten Geräten erstellt wurden, 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äte-IDs sehen, die Windows für Ihr Gerät erstellt, indem Sie den Geräte-Manager öffnen und die Hardware-IDs und kompatible IDs-Eigenschaften 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 erfolgt von der spezifischen Hardware-ID (am häufigsten bevorzugter Treiber) bis zum am wenigsten bevorzugten Treiber, sodass Treiber, die mehr über die spezifischen Features des Geräts wissen, diejenigen ersetzen können, die weniger spezifisch sind (und daher nur eine Teilmenge der Gerätefeatures unterstützen).

Gerätebezeichner sollten nur für DEN INF-Abgleich verwendet werden und sollten niemals vom Gerätetreiber analysiert oder verarbeitet werden. Wenn der Gerätetreiber die spezifische Hardware identifizieren muss, für die es geladen wurde, besteht die empfohlene Methode darin, dass die INF-Datei zur Installationszeit geeignete 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 für die Identifizierung 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 (die "Lieferanten-ID") identifiziert, und xxxx ist eine Hexadezimalzahl, die das spezifische Gerät identifiziert, das von diesem Anbieter (die "Geräte-ID") hergestellt wird. Anbieter-IDs müssen in der gesamten Branche eindeutig sein. Microsoft weist diese Zeichenfolgen zu, um sicherzustellen, dass sie eindeutig sind. Anbieter-IDs können über Plug and Play ID abgerufen werden – PNPID-Anforderung.

ACPI 5.0 unterstützt auch die Verwendung von PCI-zugewiesenen Anbieter-IDs in _HID und anderen Identifikationsobjekten, sodass Sie möglicherweise keine Anbieter-ID von Microsoft erhalten müssen. Weitere Informationen zu Hardwareidentifikationsanforderungen finden Sie unter 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 in Windows enthaltenen Inbox-Treibern kompatibel sind. Windows definiert eine Reihe von Geräte-IDs für die Verwendung mit dieser Hersteller-ID, die zum Laden des von Windows bereitgestellten Treibers für ein Gerät verwendet werden kann. Ein separates Objekt, das kompatible ID -Objekt (_CID) wird verwendet, um diese Bezeichner zurückzugeben. Windows bevorzugt immer Hardware-IDs (zurückgegeben von _HID) gegenüber kompatiblen IDs (zurückgegeben von _CID) in DER INF-Abgleichs- und Treiberauswahl. Mit dieser Einstellung kann der von Windows bereitgestellte Treiber als Standardtreiber behandelt werden, wenn ein vom Hersteller bereitgestellter gerätespezifischer Treiber nicht verfügbar ist. Die kompatiblen IDs in der folgenden Tabelle werden neu für die Verwendung mit SoC-Plattformen 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 Mitgliedschaft in einer PCI-definierten Geräteklasse angeben. Diese Objekte sind im Allgemeinen optional, können jedoch von bestimmten Geräteklassen in Windows benötigt werden. Weitere Informationen zu diesen Objekten finden Sie unter Abschnitt 6.1, "Geräteidentifikationsobjekte", der ACPI 5.0-Spezifikation.

Für die Wartungsfreundlichkeit gibt es eine Anforderung des Windows Hardware Certification Kits (HCK), dass Geräte-IDs auf OEM-Systemen "vierteilige" IDs sein müssen. Die vier Teile sind die Hersteller-ID, die Geräte-ID, die Subsystem-Hersteller-ID (OEM) und die Subsystem-Geräte-ID (OEM). 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 bietet individuelle, gerätespezifische Daten- und Steuerungsfunktionen, die von einem Gerätetreiber aufgerufen werden können, ohne mit anderen 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 definierter Funktionen, die die _DSM-Methode implementieren kann, um Daten bereitzustellen oder Steuerungsfunktionen für den Treiber auszuführen. Klassenspezifische Daten- und Datenformate werden in separaten geräteklassenspezifischen Spezifikationen bereitgestellt und werden auch in ACPI-Device-Specific-Methoden erläutert.

Adresse (_ADR) und eindeutige ID (_UID)

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

• Für Geräte, die sich mit einem hardware-seitig enumerierbaren übergeordneten Bus verbinden (z. B. SDIO, USB HSIC) und plattformspezifische Funktionen oder Steuerungen haben (z. B. Sideband-Stromversorgung oder Wake-Interrupt), wird die _HID nicht verwendet. Stattdessen wird der Gerätebezeichner vom übergeordneten Bustreiber (wie zuvor beschrieben) erstellt. In diesem Fall muss sich das Address-Objekt (_ADR) jedoch im ACPI-Namespace für das Gerät befinden. Dieses Objekt ermöglicht es dem Betriebssystem, das busenumerierte 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 dieselben Geräteidentifikationsobjekte verfügt, ist das Unique Identifier -Objekt (_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 Vom Gerät verbrauchten Systemressourcen (Speicheradressen, Unterbrechungen usw.) auch vom Aktuellen Ressourceneinstellungenobjekt (_CRS) gemeldet werden. Die Berichterstellung mehrerer möglicher Ressourcenkonfigurationen (_PRS) und Steuerelemente zum Ändern der Ressourcenkonfiguration eines Geräts (_SRS) wird unterstützt, ist jedoch 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 General Purpose I/O (GPIO) und Simple Peripheral Bus (SPB).For more information, see General Purpose I/O (GPIO) and Simple Peripheral Bus (SPB).

Auch neu für SoC-Plattformen ist ein allgemeiner, feststehender DMA-Deskriptor. Der FixedDMA-Deskriptor unterstützt die Freigabe der DMA-Controllerhardware durch eine Reihe von Systemgeräten. Die DMA-Ressourcen (Anforderungszeilen- und Kanalregister), die einem bestimmten Systemgerät zugeordnet sind, werden im FixedDMA-Deskriptor aufgeführt. Weitere Informationen finden Sie unter 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, um diese Statusänderungen an das Betriebssystem zu übermitteln. Eine Beschreibung der _STA finden Sie in Abschnitt 6.3.7 der ACPI 5.0-Spezifikation. Windows verwendet _STA, um festzustellen, ob das Gerät aufgezählt, als deaktiviert angezeigt oder für den Benutzer nicht sichtbar ist. Dieses Steuerelement in der Firmware ist für viele Anwendungen nützlich, einschließlich Docking- und USB OTG-Host-zu-Funktion-Umschalten.

Darüber hinaus stellt ACPI einen Benachrichtigungsmechanismus bereit, mit dem ASL Treiber von Ereignissen auf der Plattform benachrichtigen kann, 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 "Geräteüberprüfung" oder "Busüberprüfung" ausführen, damit Windows das Gerät erneut aufzählt und seine _STA erneut bewertet. Informationen zu ACPI-Benachrichtigungen finden Sie unter Abschnitt 5.6.6, "Geräteobjektbenachrichtigungen", der ACPI 5.0-Spezifikation.

Aktivieren/Deaktivieren

Im Rahmen von Windows Plug and Play müssen Treiber dynamisch vom Benutzer oder vom System 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 On-SoC-Geräte können von den Anforderungen zum Aktivieren und Deaktivieren ausgenommen werden. Für treiber, die nicht ausgenommen sind, gibt es Treiberschnittstellen, um anzugeben, 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), dann kann der ACPI-Namespaceknoten für das Gerät das Disable -Objekt (_DIS) enthalten. Diese Methode wird vom Betriebssystem ausgewertet, wenn der Treiber entfernt wird. Die Verwendung von _DIS hat die folgenden zusätzlichen Anforderungen:

• _STA muss das Bit "aktiviert und decodiert" löschen, wenn das Gerät deaktiviert ist.
• Das Gerät muss das Set Resource Settings (_SRS)-Objekt bereitstellen, um die Gerätehardware erneut zu aktivieren und das obige 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äteleistung wird entfernt, Treiber werden angehalten 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 (als Gerät im Namespace eines anderen Geräts aufgeführt), hängt vom übergeordneten Gerät ab. Ein USB-HSIC-Gerät hängt beispielsweise vom Anschluss (übergeordnetes Gerät) und dem Controller (Großeltern) ab, mit dem es verbunden ist. Ebenso hängt ein GPU-Gerät, das im Namespace eines Systemspeicherverwaltungsgeräts (MMU) aufgeführt ist, vom MMU-Gerät ab.

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 Einbeziehung von Verbindungsressourcen in die _CRS des Geräts beschrieben.

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

Es können auch Softwareabhängigkeiten zwischen Gerätetreibern vorhanden sein. Diese Abhängigkeiten müssen ebenfalls beschrieben werden.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Weitere Informationen zur Treiberladereihenfolge und ihren Abhängigkeiten finden Sie unter Angeben der Treiberladereihenfolge.

• Informationen zu Abhängigkeiten von Machtverhältnissen finden Sie unter:

  • IoInvalidateDeviceRelations (Rufen Sie die IoInvalidateDeviceRelations-Routine mit dem Enumerationswert DEVICE_RELATION_TYPEPowerRelations auf, um die Herstellung von Stromverbindungen einzurichten.)

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • Aufzählen der Geräte auf einem Bus

  • Dynamische Enumeration