GPIO (General-Purpose I/O)

System-on-a-Chip (SoC) integrierte Schaltkreise machen umfangreichen Einsatz von allgemeinen GPIO-Pins. Für SoC-basierte Plattformen definiert Windows eine allgemeine Abstraktion für GPIO-Hardware, und diese Abstraktion erfordert Unterstützung vom ADVANCED Configuration and Power Interface (ACPI)-Namespace.

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

Um zu überprüfen, ob Ihr GPIO-Controller alle Windows-Plattformanforderungen erfüllt, lesen Sie die Prüfliste 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 Unterbrechungen, Eingabesignalisierung und Ausgabesignalisierung. GPIO-Funktionen werden als GPIO-Controllergerät im Namespace modelliert. Die GPIO-Framework-Erweiterung (GpioClx) modelliert das GPIO-Controllergerät so, dass es in eine Reihe von Pins unterteilt wird. 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 sortiert. Beispielsweise enthält Bank 0 Pins 0-31 auf dem Controller, Bank 1 enthält Pins 32-63 usw. Alle Banken haben die gleiche Anzahl von Pins, mit Ausnahme der letzten Bank, die weniger haben könnte. 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 " weiter unten beschrieben.

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

GPIO-Controller und ActiveBoth-Unterbrechungen

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

Logisch weisen ActiveBoth-Signale sowohl einen bestätigten als auch einen nichtassertierten Zustand auf, unabhängig davon, ob es sich um momentäre Assertionen (z. B. Pushbuttons) oder unbestimmt lange Assertionen handelt (z. B. Kopfhörerbuchseneinfügungen). Die Edgeerkennung für ActiveBoth-Interrupts kann in der GPIO-Controllerhardware (Hardware ActiveBoth) implementiert oder in der GPIO-Treibersoftware (emuliertes ActiveBoth) emuliert werden. Windows erfordert, dass GPIO-Controller, die ActiveBoth implementieren, emulierte ActiveBoth verwenden müssen. Dies ist erforderlich, um eine robuste Handhabung von Unterbrechungen mit doppelter Kante 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 Pegelmodus-Interrupts unterstützen und die Polarität des Interrupts dynamisch zur Laufzeit neu programmieren können.

2. Um das Risiko von E/A-Fehlern zu minimieren, bevorzugt Windows die Verwendung speicherabgebildeter GPIO-Controller anstelle von SPB-verbundenen GPIO-Controllern. Für das Windows Button Array-Gerät (PNP0C40) ist es tatsächlich erforderlich, dass die ActiveBoth GPIO-Interrupts für dieses Gerät mit einem speicherzugeordneten GPIO-Controller und nicht mit einem über SPB verbundenen Controller verbunden sind. Informationen dazu, 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 herzustellen, 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 bestätigten Zustand des Signals bestimmt ist. Der Stapel geht weiter davon aus, dass der behauptete Zustand aller ActiveBoth-Unterbrechungslinien standardmäßig auf logischer Ebene niedrig (ActiveLow-Edge) ist. Wenn dies nicht der Fall auf Ihrer Plattform ist, können Sie die Standardeinstellung außer Kraft setzen, indem Sie den GPIO-Controller Device-Specific Method (_DSM) im Namespace des Controllers einschließen. Weitere Informationen zu dieser Methode finden Sie unter GPIO Controller Device-Specific-Methode (_DSM).

Die dritte Anforderung in der vorherigen Liste impliziert, dass der Treiber für ein Gerät, das ActiveBoth verwendet, unmittelbar nach der Initialisierung (Verbindung mit) dem Interrupt einen Interrupt erhalten kann, wenn sich das Signal an der GPIO-Pin zu diesem Zeitpunkt im bestätigten Zustand befindet. Dies ist möglich und auch für einige Geräte (z. B. Kopfhörer) möglich und muss im Treiber unterstützt werden.

Um emulierte ActiveBoth zu unterstützen, muss der GPIO-Controllertreiber die ActiveBoth-Emulation ("Opt-in to") aktivieren, indem eine CLIENT_ReconfigureInterrupt Rückruffunktion implementiert wird, und durch Festlegen des EmulateActiveBoth-Flags in der grundlegenden Informationsstruktur, die die CLIENT_QueryControllerBasicInformation Rückruffunktion des Treibers für GpioClx bereitstellt. Weitere Informationen finden Sie unter General-Purpose I/O(GPIO)-Treiber.

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 unter Abschnitt 6.4.3.8, "Verbindungsbeschreibungen", der ACPI 5.0-Spezifikation.

Geräteidentifikations- und Konfigurationsobjekte

Der ACPI-Namespace eines GPIO-Controllers umfasst Folgendes:

• Ein vom Anbieter zugewiesenes ACPI-kompatibles Hardware-ID -Objekt (_HID).
• Ein Satz von verbrauchten Ressourcen (_CRS)-Objekten.
• Ein Objekt mit eindeutiger ID (_UID), wenn mehrere Instanzen des GPIO-Controllers im Namespace vorhanden sind (d. a. 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 verbraucht werden. Die Zuordnung der Interrupt-Ressourcen zu den Bänken wird in der Reihenfolge beschrieben, in der die Interrupt-Ressourcen im _CRS aufgeführt sind, d. h., der erste aufgeführte Interrupt wird Bank 0 zugewiesen, dem nächsten aufgeführten wird Bank 1 usw. zugeordnet. Banken können Unterbrechungsressourcen teilen. In diesem Fall wird der Interrupt einmal für jede Bank, die mit ihm verbunden ist, in der Bankreihenfolge aufgeführt und als geteilt 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 Typen von GPIO-Verbindungen definieren: GPIO-Interruptverbindungen und GPIO-E/A-Verbindungen. Peripheriegeräte enthalten GPIO-Verbindungsdeskriptoren in ihrem _CRS für alle GPIO-E/A- und Unterbrechungs-Anschlüsse. Wenn ein verbundener Interrupt weckfähig ist (das System aus einem energiesparenden Leerlaufzustand wecken kann), muss er als ExclusiveAndWake oder SharedAndWake konfiguriert werden. Weitere Informationen finden Sie unter Device Power Management.

Die Beschreibungen sind in Abschnitt 6.4.3.8.1, "GPIO Connection Descriptor" 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-signalierte ACPI-Ereignisse

ACPI definiert ein Plattformereignismodell, mit dem Hardwareereignisse in der Plattform signalisiert und an den ACPI-Treiber kommuniziert werden können. Windows stellt einen Benachrichtigungsdienst für die Kommunikation von Plattformereignissen an Gerätetreiber bereit. Eine Reihe von Standardtreibern basiert auf diesem Dienst, um Unterstützung für ACPI-definierte Geräte bereitzustellen, z. B. Steuermethoden-Ein-/Ausschalter, LID-Gerät, Steuermethoden-Batterie, Thermalzone usw. Weitere Informationen zu Benachrichtigungen finden Sie unter Abschnitt 5.6.5, "GPIO-Signaled ACPI-Ereignisse", 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 mit dem 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-Ereignisinformationsobjekt (_AEI) enthalten (siehe Abschnitt 2.4.2.3.1, "ACPI Event Information (_AEI) Object", weiter unten). Die GpioInt-Ressource muss als nicht gemeinsam genutzt (Exklusiv) konfiguriert werden.

• Der Knoten des Controllers muss auch eine Edge-Steuermethode (_Exx), eine Level-Steuermethode (_Lxx) oder eine Event-Steuermethode (_EVT) für jeden Pin enthalten, der im _AEI-Objekt aufgeführt ist.

Der ACPI-Treiber behandelt den aufgeführten GPIO-Interrupt und bewertet die Flanken-, Pegel- oder Ereignissteuerungsmethode hierfür. Die Steuermethode setzt das Hardwareereignis falls erforderlich still und führt den erforderlichen Notify-Operator am Namespaceknoten des Ereignisquellengeräts aus. Windows sendet dann die Benachrichtigung an den Gerätetreiber. 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-Ereignisinformationsobjekt (_AEI) 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 diesem Gerät zugeordnet (nicht für Geräte freigegeben).

GeneralPurposeIO-Vorgangsregionen (OpRegions)

GPIO-Controller werden häufig von der Plattformfirmware verwendet, um eine beliebige Anzahl von Plattformhardwarefeatures wie das Steuern von Energie und Takten oder das Festlegen von Modi auf Geräten zu unterstützen. Um die Verwendung von GPIO I/O aus ASL-Steuerelementmethoden zu unterstützen, definiert ACPI 5.0 einen neuen OpRegion-Typ "GeneralPurposeIO".

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

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

Da der OpRegion-Zugriff vom GPIO-Controllergerätetreiber (dem "OpRegion Handler") bereitgestellt wird, müssen Methoden darauf achten, erst dann auf einen OpRegion-Zugriff zuzugreifen, wenn der Treiber verfügbar ist. ASL-Code kann den Status des OpRegion-Handlers nachverfolgen, indem eine Region (_REG)-Methode unter dem GPIO-Controllergerät eingeschlossen wird (siehe Abschnitt 6.5.4 der ACPI 5.0-Spezifikation). Darüber hinaus lässt sich das OpRegion-Dependencies (_DEP)-Objekt (siehe Abschnitt 6.5.8 der ACPI 5.0-Spezifikation) bei jedem Gerät verwenden, das eine Methode hat, die bei Bedarf auf GPIO-OpRegion-Felder zugreift. Siehe den Abschnitt "Geräteabhängigkeiten" im Thema "Geräteverwaltungsnamespaceobjekte" für eine Diskussion darüber, wann _DEP verwendet werden sollte. Es ist wichtig, dass Treibern keine GPIO-E/A-Ressourcen zugewiesen sind, die auch GeneralPurposeIO OpRegions zugeordnet sind. Opregions dienen der exklusiven Verwendung von ASL-Steuerungsmethoden.