GPIO (E/S universelle)

Les circuits intégrés Système sur puce (SoC) utilisent largement les broches d’E/S à usage général (GPIO). Pour les plateformes basées sur SoC, Windows définit une abstraction générale pour le matériel GPIO, et cette abstraction nécessite la prise en charge de l’espace de noms ACPI (Advanced Configuration and Power Interface).

L’abstraction GPIO est prise en charge par les définitions de spécification ACPI 5.0 répertoriées dans cet article.

Pour vérifier que votre contrôleur GPIO répond à toutes les exigences de la plateforme Windows, consultez Liste de vérification des exigences du contrôleur GPIO.

Périphériques contrôleurs GPIO

Windows prend en charge les contrôleurs GPIO. Les contrôleurs GPIO fournissent diverses fonctions pour les périphériques, notamment les interruptions, la signalisation d’entrée et la signalisation de sortie. Les fonctionnalités GPIO sont modélisées en tant qu’appareil contrôleur GPIO dans l’espace de noms. L’extension d’infrastructure GPIO (GpioClx) modélise l’appareil du contrôleur GPIO comme étant partitionné dans un certain nombre de banques de broches. Chaque banque de broches a au moins 64 broches configurables. Les banques d’un contrôleur GPIO sont classées par rapport à la position de leurs broches dans l’espace de broche GPIO relatif au contrôleur. Par exemple, la banque 0 contient les broches 0-31 sur le contrôleur, la banque 1 contient les broches 32-63, et ainsi de suite. Toutes les banques ont le même nombre d’épingles, à l’exception de la dernière banque, qui peut en avoir moins. Les banques sont importantes pour le microprogramme ACPI, car le microprogramme doit signaler le mappage des ressources d’interruption système aux banques, comme décrit dans la section Objets d’espace de noms GPIO ci-dessous.

Chaque broche d’une banque a un ensemble de paramètres (par exemple, sortie, interruption sensible au niveau, entrée dé-rebondie, etc.) qui décrivent comment la broche doit être configurée.

Contrôleurs GPIO et interruptions ActiveBoth

Une fonctionnalité de certains contrôleurs GPIO est la possibilité de générer des interruptions sur les deux bords d’un signal (arêtes montantes ou ActiveHigh, et tombantes, ou bords ActiveLow). Cela est utile dans diverses applications, y compris l’interface de bouton, où les événements d’appui sur bouton (un bord) et les événements de libération de bouton (le bord opposé) sont significatifs. Cette fonctionnalité est appelée « ActiveBoth ».

Logiquement, les signaux ActiveBoth ont à la fois un état affirmé et un état non affirmé, qu’il s’agisse d’assertions momentanées (par exemple, boutons pushbuttons) ou d’assertions indéfiniment longues (par exemple, insertions de prise casque). La détection de périphérie pour les interruptions ActiveBoth peut être implémentée dans le matériel du contrôleur GPIO (ActiveBoth matériel) ou être émulée dans le logiciel pilote GPIO (ActiveBoth émulé). Windows exige que les contrôleurs GPIO qui implémentent ActiveBoth utilisent ActiveBoth émulé. Cela est nécessaire pour garantir une gestion robuste des interruptions à double tranchant pour tous les scénarios. Pour prendre en charge l’émulation ActiveBoth, la configuration matérielle requise suivante s’applique :

1. Les contrôleurs GPIO qui prennent en charge les interruptions ActiveBoth doivent prendre en charge les interruptions en mode niveau et doivent prendre en charge la programmation dynamique de la polarité de l’interruption au moment de l’exécution.

2. Pour réduire le risque d’erreurs d’E/S, Windows préfère utiliser des contrôleurs GPIO mappés en mémoire au lieu de contrôleurs GPIO connectés à SPB. En fait, pour l’appareil Windows Button Array (PNP0C40), il est nécessaire que le GPIO ActiveBoth interrompt pour cet appareil se connectent à un contrôleur GPIO mappé en mémoire, et non à un contrôleur SPB connecté. Pour déterminer les interruptions de bouton qui doivent être ActiveBoth, consultez la section Périphériques de bouton dans la rubrique Autres objets d’espace de noms ACPI .

3. Pour établir un état initial déterministe pour les signaux d’interruption ActiveBoth, la pile d’appareils Windows GPIO garantit que la première interruption générée après la connexion de l’interruption par le pilote sera toujours pour l’état déclaré du signal. La pile suppose en outre que l’état déclaré de toutes les lignes d’interruption ActiveBoth est de niveau logique bas (bord ActiveLow) par défaut. Si ce n’est pas le cas sur votre plateforme, vous pouvez remplacer la valeur par défaut en incluant le contrôleur GPIO Device-Specific Method (_DSM) dans l’espace de noms du contrôleur. Pour plus d’informations sur cette méthode, consultez GpIO Controller Device-Specific Method (_DSM).

La troisième exigence de la liste précédente implique que le pilote d’un appareil qui utilise ActiveBoth peut recevoir une interruption immédiatement après l’initialisation (connexion à) l’interruption, si le signal au niveau de la broche GPIO est dans l’état déclaré à ce moment-là. Cela est possible et même probable pour certains appareils (par exemple, les casques) et doit être pris en charge dans le pilote.

Pour prendre en charge ActiveBoth émulé, le pilote du contrôleur GPIO doit activer l’émulation ActiveBoth (« s’inscrire à ») en implémentant une fonction de rappel CLIENT_ReconfigureInterrupt et en définissant l’indicateur EmulateActiveBoth dans la structure d’informations de base que la fonction de rappel CLIENT_QueryControllerBasicInformation du pilote fournit à GpioClx. Pour plus d’informations, consultez Pilotes d’E/S à usage général (GPIO).

Objets d’espace de noms GPIO

Les contrôleurs GPIO et les périphériques qui s’y connectent sont énumérés par ACPI. La connexion entre eux est décrite à l’aide des descripteurs de ressources de connexion GPIO. Pour plus d’informations, consultez la section 6.4.3.8, « Descripteurs de connexion », de la spécification ACPI 5.0.

Objets d’identification et de configuration des appareils

L’espace de noms ACPI d’un appareil de contrôleur GPIO comprend les éléments suivants :

• Objet d’ID matériel (_HID) conforme ACPI attribué par le fournisseur.
• Ensemble de ressources consommées (_CRS) objet.
• Objet ID unique (_UID), s’il existe plusieurs instances du contrôleur GPIO dans l’espace de noms (autrement dit, deux nœuds d’espace de noms ou plus qui ont les mêmes objets d’identification d’appareil).

La _CRS du contrôleur GPIO contient toutes les ressources (espace d’adressage pour les registres, interruptions système, etc.) consommées par toutes les banques du contrôleur GPIO. Le mappage de ressource d’interruption à banque est représenté dans l’ordre dans lequel les ressources d’interruption sont répertoriées dans le _CRS, c’est-à-dire que la première interruption répertoriée est affectée à la banque 0, la suivante répertoriée est affectée à la banque 1, et ainsi de suite. Les banques peuvent partager des ressources d’interruption, auquel cas l’interruption est répertoriée une fois pour chaque banque qui y est connectée, dans l’ordre bancaire, et est configurée comme partagée.

Descripteurs de ressources de connexion GPIO

La relation entre les périphériques et les broches GPIO auxquelles ils sont connectés est décrite au système d’exploitation par les descripteurs de ressources de connexion GPIO. Ces descripteurs de ressources peuvent définir deux types de connexions GPIO : les connexions d’interruption GPIO et les connexions d’E/S GPIO. Les périphériques incluent des descripteurs de connexion GPIO dans leur _CRS pour toutes les broches d’E/S et d’interruption GPIO connectées. Si une interruption connectée est compatible avec la veille (capable de sortir le système d’un état d’inactivité à faible consommation d’énergie), elle doit être configurée en tant que ExclusiveAndWake ou SharedAndWake. Pour plus d’informations, consultez Gestion de l’alimentation des appareils.

Les descripteurs sont définis dans la section 6.4.3.8.1, « Descripteur de connexion GPIO », de la spécification ACPI 5.0. Les macros de modèle de ressource ASL pour ces descripteurs sont décrites dans la section 19.5.53, « GpioInt (GpIO Interrupt Connection Resource Descriptor Macro) », de la spécification ACPI 5.0.

Événements ACPI signalés par GPIO

ACPI définit un modèle d’événement de plateforme qui permet aux événements matériels de la plateforme d’être signalés et communiqués au pilote ACPI. Windows fournit un service de notification pour la communication des événements de plateforme aux pilotes de périphérique. Un certain nombre de pilotes de boîte de réception s’appuient sur ce service pour assurer la prise en charge des appareils définis par ACPI, tels que le bouton d’alimentation de la méthode de contrôle, le périphérique LID, la batterie de méthode de contrôle, la zone thermique, etc. Pour plus d’informations sur les notifications, consultez la section 5.6.5, « Événements ACPI signalés par GPIO », de la spécification ACPI.

Pour les plateformes SoC, les interruptions GPIO sont utilisées pour signaler les événements de plateforme. Tout appareil d’espace de noms (« appareil ACPI Event Source ») qui signale des événements à son pilote à l’aide de l’opérateur ASL Notify nécessite les éléments suivants :

• Le nœud d’espace de noms du contrôleur GPIO auquel le signal d’événement ACPI est connecté doit inclure une ressource GpioInt pour cette broche dans son objet Informations sur les événements ACPI (_AEI) (voir la section 2.4.2.3.1, « ACPI Event Information (_AEI) Object », ci-dessous). La ressource GpioInt doit être configurée comme non partagée (exclusive).

• Le nœud du contrôleur doit également contenir une méthode de contrôle Edge (_Exx), Level (_Lxx) ou Event (_EVT) pour chaque broche répertoriée dans l’objet _AEI.

Le pilote ACPI gère l’interruption GPIO répertoriée et évalue la méthode de contrôle Edge, Level ou Event pour celle-ci. La méthode de contrôle arrête l’événement matériel, si nécessaire, et exécute l’opérateur Notify requis sur le nœud d’espace de noms de l’appareil source de l’événement. Windows envoie ensuite la notification au pilote de l’appareil. Plusieurs événements peuvent être signalés sur la même ressource GpioInt si la méthode de contrôle d’événement peut interroger le matériel pour déterminer l’événement qui s’est produit. La méthode doit ensuite notifier l’appareil approprié avec le code de notification correct.

Objet _AEI d’informations sur les événements ACPI Comme mentionné précédemment, l’espace de noms du contrôleur GPIO doit contenir l’objet _AEI afin de prendre en charge les événements ACPI. L’objet _AEI (voir la section 5.6.5.2 de la spécification ACPI 5.0) retourne une mémoire tampon de modèle de ressource contenant uniquement des descripteurs GpioInt qui signalent des événements ACPI via ce contrôleur GPIO. Chaque descripteur correspond à un appareil source d’événement ACPI et est dédié à cet appareil (non partagé entre les appareils).

Régions d’opération GeneralPurposeIO (OpRegions)

Les contrôleurs GPIO sont souvent utilisés par le microprogramme de la plateforme pour prendre en charge un certain nombre de fonctionnalités matérielles de plateforme, telles que le contrôle de l’alimentation et des horloges, ou la définition des modes sur les appareils. Pour prendre en charge l’utilisation d’E/S GPIO à partir de méthodes de contrôle ASL, ACPI 5.0 définit un nouveau type OpRegion, « GeneralPurposeIO ».

GeneralPurposeIO OpRegions (voir la section 5.5.2.4.4 de la spécification ACPI 5.0) sont déclarées dans l’étendue de l’espace de noms du périphérique du contrôleur GPIO dont le pilote gérera les E/S. Les déclarations de champ GeneralPurposeIO (voir la section 5.5.2.4.4.1 de la spécification ACPI 5.0) attribuent des noms aux broches GPIO accessibles dans une oprégion GeneralPurposeIO. Les ressources de connexion GpioIO (voir la section 19.5.53 de la spécification ACPI 5.0) sont utilisées dans la déclaration Field pour spécifier le ou les numéros de broche et la configuration d’une référence de champ particulière. Le nombre total de bits de champ nommés suivant un descripteur de connexion doit être égal au nombre de broches répertoriées dans le descripteur.

Les champs d’une OpRegion peuvent être déclarés n’importe où dans l’espace de noms et accessibles à partir de n’importe quelle méthode de l’espace de noms. Le sens des accès à une OpRegion GeneralPurposeIO est déterminé par le premier accès (lecture ou écriture) et ne peut pas être modifié.

Étant donné que l’accès OpRegion est fourni par le pilote de périphérique du contrôleur GPIO (le « gestionnaire OpRegion »), les méthodes doivent veiller à ne pas accéder à un OpRegion tant que le pilote n’est pas disponible. Le code ASL peut suivre l’état du gestionnaire OpRegion en incluant une méthode Region (_REG) sous le périphérique de contrôleur GPIO (voir la section 6.5.4 de la spécification ACPI 5.0). En outre, l’objet OpRegion Dependencies (_DEP) (voir la section 6.5.8 de la spécification ACPI 5.0) peut être utilisé sous n’importe quel appareil disposant d’une méthode accédant aux champs OpRegion GPIO, si nécessaire. Pour savoir quand utiliser _DEP, consultez la section Dépendances d’appareil de la rubrique Objets d’espace de noms de gestion des appareils. Il est important que les pilotes ne se voient pas attribuer de ressources d’E/S GPIO qui sont également affectées à GeneralPurposeIO OpRegions. Les régions sont destinées à l’utilisation exclusive des méthodes de contrôle ASL.