Partitionieren eines GPIO-Controllers in Banks of Pins

Ein Treiberentwickler kann optional ein GPIO-Controllergerät (General Purpose E/O) in zwei oder mehr Banken von GPIO-Pins partitionieren. Beispielsweise kann ein GPIO-Controllergerät mit 64 GPIO-Pins vom GPIO-Controllertreiber als zwei Banken beschrieben werden, von denen jede über 32 GPIO-Pins verfügt. Der Entwickler kann einen einzelnen Treiber bereitstellen, um alle Banken in einem GPIO-Controllergerät zu verwalten, und dieser Treiber verwendet in der Regel ein Geräteobjekt, um das gesamte Gerät darzustellen. Einige oder alle Banken im Gerät können jedoch unabhängig von den anderen Banken im Gerät verwaltet werden.

In der Regel entscheidet sich ein GPIO-Controllertreiber aus einem der folgenden Gründe dafür, einen GPIO-Controller in zwei oder mehr Banken zu partitionieren:

• Der Leistungszustand der GPIO-Pins in einer Bank kann unabhängig von den Pins in den anderen Banken verwaltet werden.
• Die Gesamtzahl der Pins im GPIO-Controller ist größer als 64.

Die maximale Bankgröße, die von der GPIO-Frameworkerweiterung (GpioClx) unterstützt wird, beträgt 64 Pins. Ein GPIO-Controllergerät, das mehr als 64 Pins enthält, muss vom Treiber in zwei oder mehr Banken partitioniert werden, von denen jede nicht mehr als 64 Pins enthält.

Um zu bestimmen, wie ein GPIO-Controller in Banken partitioniert wird, ruft GpioClx die CLIENT_QueryControllerBasicInformation Ereignisrückruffunktion auf. Diese Funktion, die vom GPIO-Controllertreiber implementiert wird, stellt eine CLIENT_CONTROLLER_BASIC_INFORMATION-Struktur bereit, die die Attribute und Funktionen des GPIO-Controllers beschreibt. Zwei Member dieser Struktur, TotalPins und NumberOfPinsPerBank, geben an, wie die Pins im GPIO-Controller in Banken partitioniert werden. TotalPins gibt die Gesamtzahl der Pins im GPIO-Controller an, und NumberOfPinsPerBank gibt die Anzahl der Pins pro Bank an. Wenn N die Anzahl der Banken im Controller ist, werden die Banken von 0 bis N–1 nummeriert. Alle mit Ausnahme der letzten Bank (d. h. die Banknummer N–1) müssen die Anzahl der Pins enthalten, die im NumberOfPinsPerBank-Mitglied angegeben ist. Die letzte Bank kann über eine beliebige Anzahl von Pins von 1 bis NumberOfPinsPerBank verfügen.

GpioClx bestimmt die Gesamtzahl der Banken im GPIO-Controller aus den Werten der Mitglieder TotalPins und NumberOfPinsPerBank . GpioClx verwendet die folgende ganzzahlige Formel, um die Gesamtzahl der Banken zu berechnen:

(TotalPins + NumberOfPinsPerBank – 1) / NumberOfPinsPerBank In einigen GPIO-Controller-Geräten kann eine Bank von Pins in einem Gerät unabhängig von den anderen Banken im selben Gerät aktiviert oder in einen Energiesparzustand umgeschaltet werden. Wenn sich also eine bestimmte Bank im Leerlauf befindet, kann diese Bank in einen Energiesparzustand umgestellt werden, um den Stromverbrauch zu reduzieren. Um solche Geräte aufzunehmen, unterstützt GpioClx die Energieverwaltung auf Komponentenebene. GpioClx definiert zwei Leistungszustände auf Komponentenebene: F0 (vollständig aktiviert) und F1 (low-power oder off).

Um zu bestimmen, ob eine Bank von GPIO-Pins die Energieverwaltung auf Komponentenebene unterstützt, ruft GpioClx die CLIENT_QuerySetControllerInformation Ereignisrückruffunktion auf. Der InputBuffer-Parameter dieser Funktion ist ein Zeiger auf eine CLIENT_CONTROLLER_QUERY_SET_INFORMATION_INPUT-Struktur . Um Energieverwaltungsinformationen anzufordern, legt der Aufrufer den RequestType-Member dieser Struktur auf QueryBankPowerInformation fest.

Wenn eine GPIO-Bank die Energieverwaltung auf Komponentenebene unterstützt, ermöglicht GpioClx den Übergang zum F1-Energiezustand, wenn sich die Bank im Leerlauf befindet. Bevor die Bank in den F1-Zustand wechselt, ruft GpioClx die CLIENT_SaveBankHardwareContext Ereignisrückruffunktion auf, um den Treiber anzufordern, den Hardwarekontext (hauptsächlich den Registerinhalt) der Bank zu speichern. Später, nachdem die Bank den F0-Zustand eingegeben hat, ruft GpioClx die CLIENT_RestoreBankHardwareContext Ereignisrückruffunktion auf, um den Treiber anzufordern, den zuvor gespeicherten Hardwarekontext wiederherzustellen.