GPIO (General-Purpose I/O)

  • Artikel

Integrierte SoC-Leitungen (System on a Chip) nutzen umfangreiche GPIO-Pins (General Purpose E/O). Für SoC-basierte Plattformen definiert Windows eine allgemeine Abstraktion für GPIO-Hardware, und diese Abstraktion erfordert Unterstützung vom ACPI-Namespace (Advanced Configuration and Power Interface).

Die GPIO-Abstraktion wird von den ACPI 5.0-Spezifikationsdefinitionen unterstützt, die in diesem Artikel aufgeführt sind.

Informationen zum Überprüfen, ob Ihr GPIO-Controller alle Windows-Plattformanforderungen erfüllt, finden Sie unter Checkliste für GPIO-Controlleranforderungen.

GPIO-Controllergeräte

Windows unterstützt GPIO-Controller. GPIO-Controller bieten eine Vielzahl von Funktionen für Peripheriegeräte, einschließlich Interrupts, Eingabesignalisierung und Ausgabesignalisierung. GPIO-Funktionen werden als GPIO-Controllergerät im Namespace modelliert. Die GPIO-Frameworkerweiterung (GpioClx) modelliert das GPIO-Controllergerät als partitioniert in eine Reihe von Pinbanken. Jede Pinbank verfügt über 64 oder weniger konfigurierbare Pins. Die Banken in einem GPIO-Controller werden relativ zur Position ihrer Pins innerhalb des controllerrelativen GPIO-Pinraums angeordnet. Bank 0 enthält beispielsweise die Pins 0 bis 31 auf dem Controller, Bank 1 die Pins 32 bis 63 usw. Alle Banken haben die gleiche Anzahl von Pins, mit Ausnahme der letzten Bank, die möglicherweise weniger hat. Banken sind für die ACPI-Firmware von Bedeutung, da die Firmware die Zuordnung von Systemunterbrechungsressourcen zu Banken melden muss, wie im Abschnitt GPIO-Namespaceobjekte unten beschrieben.

Jeder Pin auf einer Bank verfügt über einen Satz von Parametern (z. B. Ausgabe, levelsensitiver Interrupt, Unzustellbarkeit von Eingaben usw.), die beschreiben, wie der Pin konfiguriert werden soll.

GPIO-Controller und ActiveBoth-Interrupts

Ein Feature einiger GPIO-Controller ist die Möglichkeit, Interrupts an beiden Rändern eines Signals (steigende oder ActiveHigh-Kanten und fallende Oder ActiveLow-Kanten) zu generieren. Dies ist in einer Vielzahl von Anwendungen nützlich, einschließlich der Schaltflächenschnittstelle, wobei sowohl Tastendruckereignisse (eine Kante) als auch Schaltflächenfreigabeereignisse (die gegenüberliegende Kante) sinnvoll sind. Dieses Feature wird als "ActiveBoth" bezeichnet.

Logischerweise weisen ActiveBoth-Signale sowohl einen behaupteten als auch einen nicht überprüften Zustand auf, unabhängig davon, ob es sich um momentäre Assertionen (z. B. Drucktasten) oder um unbestimmt lange Assertionen (z. B. Kopfhörerbuchseneinfügungen) handelt. Die Edgeerkennung für ActiveBoth-Interrupts kann in der GPIO-Controllerhardware (Hardware ActiveBoth) implementiert oder in der GPIO-Treibersoftware emuliert werden (emuliertes ActiveBoth). Windows erfordert, dass GPIO-Controller, die ActiveBoth implementieren, emuliertes ActiveBoth verwenden müssen. Dies ist erforderlich, um eine stabile Behandlung von zweischneidigen Interrupts für alle Szenarien sicherzustellen. Zur Unterstützung der ActiveBoth-Emulation gelten die folgenden Hardwareanforderungen:

  1. GPIO-Controller, die ActiveBoth-Interrupts unterstützen, müssen Unterbrechungen im Pegelmodus unterstützen und die erneute Programmierung der Polarität des Interrupts dynamisch zur Laufzeit unterstützen.

  2. Um das Risiko von E/A-Fehlern zu minimieren, bevorzugt Windows die Verwendung speicherseitig zugeordneter GPIO-Controller anstelle von MIT SPB verbundenen GPIO-Controllern. Für das Windows Button Array-Gerät (PNP0C40) ist es in der Tat erforderlich, dass der ActiveBoth GPIO für dieses Gerät eine Verbindung mit einem speicherbasierten GPIO-Controller herstellt und nicht mit einem SPB verbunden ist. Informationen zum Ermitteln, welche Schaltflächenunterbrechungen ActiveBoth sein müssen, finden Sie im Abschnitt Schaltflächengeräte im Thema Andere ACPI-Namespaceobjekte .

  3. Um einen deterministischen Anfangszustand für ActiveBoth-Interruptsignale einzurichten, garantiert der Windows GPIO-Gerätestapel, dass der erste Interrupt, der nach der Verbindung des Interrupts durch den Treiber generiert wird, immer für den behaupteten Zustand des Signals ist. Der Stapel geht weiter davon aus, dass der behauptete Zustand aller ActiveBoth-Interruptzeilen standardmäßig auf Logikebene niedrig (ActiveLow-Edge) ist. Wenn dies auf Ihrer Plattform nicht der Fall ist, können Sie den Standardwert überschreiben, indem Sie den GPIO-Controller Device-Specific Method (_DSM) in den Namespace des Controllers einschließen. Weitere Informationen zu dieser Methode finden Sie unter GPIO Controller Device-Specific Method (_DSM).

Die dritte Anforderung in der vorherigen Liste impliziert, dass der Treiber für ein Gerät, das ActiveBoth verwendet, einen Interrupt direkt nach dem Initialisieren (Herstellen einer Verbindung mit) des Interrupts empfängt, wenn sich das Signal am GPIO-Pin zu diesem Zeitpunkt im behaupteten Zustand befindet. Dies ist möglich und wahrscheinlich sogar für einige Geräte (z. B. Kopfhörer) und muss im Treiber unterstützt werden.

Um emuliertes ActiveBoth zu unterstützen, muss der GPIO-Controllertreiber die ActiveBoth-Emulation aktivieren ("Opt-In to"), indem er eine CLIENT_ReconfigureInterrupt Rückruffunktion implementiert und das EmulateActiveBoth-Flag in der grundlegenden Informationsstruktur festlegt, die die CLIENT_QueryControllerBasicInformation Rückruffunktion des Treibers an GpioClx bereitstellt. Weitere Informationen finden Sie unter GpIO-Treiber (General-Purpose E/O).

GPIO-Namespaceobjekte

GPIO-Controller und die Peripheriegeräte, die mit ihnen verbunden sind, werden von ACPI aufgezählt. Die Verbindung zwischen ihnen wird mithilfe von GPIO-Verbindungsressourcendeskriptoren beschrieben. Weitere Informationen finden Sie in Abschnitt 6.4.3.8, "Verbindungsdeskriptoren" der ACPI 5.0-Spezifikation.

Geräteidentifikations- und Konfigurationsobjekte

Der ACPI-Namespace eines GPIO-Controllergeräts umfasst Folgendes:

  • Ein vom Anbieter zugewiesenes ACPI-kompatibles Hardware-ID-Objekt (_HID).
  • Eine Reihe von ressourcenverbrauchten Objekten (_CRS).
  • Ein Eindeutiges ID-Objekt (_UID), wenn mehr als eine Instanz des GPIO-Controllers im Namespace vorhanden ist (also zwei oder mehr Namespaceknoten mit denselben Geräteidentifikationsobjekten).

Die _CRS des GPIO-Controllers enthält alle Ressourcen (Adressraum für Register, Systemunterbrechungen usw.), die von allen Banken im GPIO-Controller genutzt werden. Die Interruptressourcenzuordnung wird in der Reihenfolge dargestellt, in der die Interruptressourcen in der _CRS aufgeführt werden. Das heißt, der erste aufgeführte Interrupt wird Bank 0 zugewiesen, der nächste aufgeführte wird Bank 1 zugewiesen usw. Banken können Interruptressourcen gemeinsam nutzen. In diesem Fall wird der Interrupt einmal für jede Bank aufgeführt, die mit ihr verbunden ist, in Bankreihenfolge und als Freigegeben konfiguriert.

GPIO-Verbindungsressourcendeskriptoren

Die Beziehung zwischen Peripheriegeräten und den GPIO-Pins, mit denen sie verbunden sind, wird durch GPIO-Verbindungsressourcendeskriptoren mit dem Betriebssystem beschrieben. Diese Ressourcendeskriptoren können zwei Arten von GPIO-Verbindungen definieren: GPIO-Interruptverbindungen und GPIO-E/A-Verbindungen. Peripheriegeräte enthalten GPIO-Verbindungsdeskriptoren in ihrer _CRS für alle verbundenen GPIO-E/A- und Interruptpins. Wenn ein verbundener Interrupt reaktiviert ist (in der Lage ist, das System aus einem Leerlaufzustand mit geringer Leistung zu wecken), muss er als ExclusiveAndWake oder SharedAndWake konfiguriert werden. Weitere Informationen finden Sie unter Geräteenergieverwaltung.

Die Deskriptoren werden in Abschnitt 6.4.3.8.1, "GPIO-Verbindungsdeskriptor", der ACPI 5.0-Spezifikation definiert. Die ASL-Ressourcenvorlagenmakros für diese Deskriptoren werden in Abschnitt 19.5.53, "GpioInt (GPIO Interrupt Connection Resource Descriptor Macro)" der ACPI 5.0-Spezifikation beschrieben.

GPIO-signalisierter ACPI-Ereignisse

ACPI definiert ein Plattformereignismodell, mit dem Hardwareereignisse auf der Plattform signalisiert und an den ACPI-Treiber übermittelt werden können. Windows bietet einen Benachrichtigungsdienst für die Kommunikation von Plattformereignissen mit Gerätetreibern. Eine Reihe von Posteingangstreibern ist von diesem Dienst abhängig, um Unterstützung für ACPI-definierte Geräte bereitzustellen, z. B. Ein-/Ausschalter der Steuerungsmethode, LID-Gerät, Steuermethodebatterie, Thermische Zone usw. Weitere Informationen zu Benachrichtigungen finden Sie in Abschnitt 5.6.5, "GPIO-Signaled ACPI Events" der ACPI-Spezifikation.

Für SoC-Plattformen werden GPIO-Interrupts verwendet, um Plattformereignisse zu signalisieren. Jedes Namespacegerät ("ACPI Event Source"-Gerät), das Ereignisse über den ASL Notify-Operator an seinen Treiber signalisiert, erfordert Folgendes:

  • Der Namespaceknoten des GPIO-Controllers, mit dem das ACPI-Ereignissignal verbunden ist, muss eine GpioInt-Ressource für diesen Pin in seinem ACPI Event Information -Objekt (_AEI) enthalten (siehe Abschnitt 2.4.2.3.1, "ACPI Event Information (_AEI) Object", unten). Die GpioInt-Ressource muss als nicht freigegeben (Exklusiv) konfiguriert werden.

  • Der Knoten des Controllers muss auch eine Edge -Steuerungsmethode (_Exx), level (_Lxx) oder Ereignis (_EVT) für jeden im _AEI-Objekt aufgeführten Pin enthalten.

Der ACPI-Treiber verarbeitet den aufgeführten GPIO-Interrupt und wertet die Edge-, Level- oder Ereignissteuerungsmethode dafür aus. Die Steuerungsmethode löscht bei Bedarf das Hardwareereignis und führt den erforderlichen Notify-Operator auf dem Namespaceknoten des Ereignisquellengeräts aus. Windows sendet die Benachrichtigung dann an den Treiber des Geräts. Mehrere Ereignisse können über dieselbe GpioInt-Ressource signalisiert werden, wenn die Ereignissteuerungsmethode die Hardware abfragen kann, um zu bestimmen, welches Ereignis aufgetreten ist. Die -Methode muss dann das richtige Gerät mit dem richtigen Benachrichtigungscode benachrichtigen.

ACPI Event Information (_AEI)-Objekt Wie bereits erwähnt, muss der Namespace des GPIO-Controllers das _AEI-Objekt enthalten, um ACPI-Ereignisse zu unterstützen. Das _AEI -Objekt (siehe Abschnitt 5.6.5.2 in der ACPI 5.0-Spezifikation) gibt einen Ressourcenvorlagenpuffer zurück, der nur GpioInt-Deskriptoren enthält, die ACPI-Ereignisse über diesen GPIO-Controller signalisieren. Jeder Deskriptor entspricht einem ACPI-Ereignisquellgerät und ist für dieses Gerät dedizierte (nicht für Geräte freigegeben).

GeneralPurposeIO-Vorgangsregionen (OpRegions)

GPIO-Controller werden häufig von der Plattformfirmware verwendet, um eine beliebige Anzahl von Hardwarefeatures der Plattform zu unterstützen, z. B. die Steuerung von Energie und Uhren oder das Festlegen von Modi auf Geräten. Um die Verwendung von GPIO-E/A von ASL-Steuerungsmethoden zu unterstützen, definiert ACPI 5.0 den neuen OpRegion-Typ "GeneralPurposeIO".

GeneralPurposeIO OpRegions (siehe Abschnitt 5.5.2.4.4 der ACPI 5.0-Spezifikation) werden innerhalb des Namespacebereichs des GPIO-Controllergeräts deklariert, dessen Treiber die E/A verarbeitet. GeneralPurposeIO Field-Deklarationen (siehe Abschnitt 5.5.2.4.4.1 der ACPI 5.0-Spezifikation) weisen GPIO-Pins Namen zu, auf die innerhalb einer GeneralPurposeIO-OpRegion zugegriffen werden soll. GpioIO-Verbindungsressourcen (siehe Abschnitt 19.5.53 der ACPI 5.0-Spezifikation) werden in der Field-Deklaration verwendet, um die Pinnummer(en) und die Konfiguration für einen bestimmten Field-Verweis anzugeben. Die Gesamtzahl der benannten Feldbits, die einem Verbindungsdeskriptor folgen, muss der Anzahl der im Deskriptor aufgeführten Pins entsprechen.

Felder in einer OpRegion können an einer beliebigen Stelle im Namespace deklariert und von jeder Methode im Namespace aus zugegriffen werden. Die Richtung des Zugriffs auf eine GeneralPurposeIO-OpRegion wird durch den ersten Zugriff (Lese- oder Schreibzugriff) bestimmt und kann nicht geändert werden.

Da der OpRegion-Zugriff vom GPIO-Controller-Gerätetreiber (der "OpRegion-Handler") bereitgestellt wird, müssen Methoden darauf achten, erst dann auf eine OpRegion zuzugreifen, wenn der Treiber verfügbar ist. ASL-Code kann den Zustand des OpRegion-Handlers nachverfolgen, indem er eine Region -Methode (_REG) unter das GPIO-Controllergerät einschließt (siehe Abschnitt 6.5.4 der ACPI 5.0-Spezifikation). Darüber hinaus kann das OpRegion Dependencies-Objekt (_DEP) (siehe Abschnitt 6.5.8 der ACPI 5.0-Spezifikation) unter jedem Gerät verwendet werden, das über eine Methode verfügt, die auf GPIO OpRegion-Felder zugreift, falls erforderlich. Informationen zur Verwendung von _DEP finden Sie im Abschnitt Geräteabhängigkeiten im Thema Geräteverwaltungsnamespaceobjekte . Es ist wichtig, dass Treiber keine GPIO-E/A-Ressourcen zugewiesen werden, die auch GeneralPurposeIO OpRegions zugewiesen sind. Opregionen dienen der ausschließlichen Verwendung von ASL-Steuerungsmethoden.