Développement du pilote de périphérique Linux :le sous-système de contrôle des broches

Note de l'éditeur :le noyau Linux intégré joue déjà un rôle essentiel dans les systèmes embarqués et va gagner en importance pour répondre aux diverses exigences de l'Internet des objets (IoT). À leur tour, les pilotes d'appareils fournissent le lien critique entre les applications et les appareils IoT eux-mêmes. Dans Linux Device Drivers Development, l'auteur John Madieu offre un aperçu complet du développement de ces pilotes, combinant une explication détaillée avec de nombreux exemples de code.

Cet extrait, chapitre 14 du livre, se concentre sur le contrôle des broches et les GPIO, un domaine particulièrement important pour les développeurs de systèmes embarqués cherchant à interagir avec des périphériques matériels personnalisés. Ce premier volet de cet extrait présente le sous-système de contrôle des broches.

Adapté de Linux Device Drivers Development, par John Madieu.

Chapitre 14. Contrôle des broches et sous-système GPIO
Par John Madieu

La plupart des ingénieurs du noyau et des pilotes Linux embarqués écrivent à l'aide de GPIO ou jouent avec le multiplexage de broches. Par broches, j'entends la ligne sortante du composant. Le SoC multiplexe les broches, ce qui signifie qu'une broche peut avoir plusieurs fonctions, par exemple, MX6QDL_PAD_SD3_DAT1 dans arch/arm/boot/dts/imx6dl-pinfunc.h peut être soit une ligne de données SD3, 1, les cts/rts de UART1, le Rx de Flexcan2 ou GPIO normal.

Le mécanisme par lequel on choisit le mode sur lequel une broche doit fonctionner est appelé multiplexage de broches. Le système responsable s'appelle le contrôleur de broche. Dans la deuxième partie du chapitre, nous discuterons de la sortie d'entrée à usage général (GPIO ), qui est une fonction spéciale (mode) dans laquelle une broche peut fonctionner.

Dans ce chapitre, nous allons :

Parcourez le sous-système de contrôle des broches et voyez comment déclarer leurs nœuds dans DT
Explorez les deux anciennes interfaces GPIO basées sur des entiers, ainsi que la nouvelle API d'interface basée sur des descripteurs
Traitement avec GPIO mappé sur IRQ
Gérer les interfaces sysfs dédiées aux GPIO

Sous-système de contrôle des broches

Le Contrôle Pin (pinctrl ) permet de gérer le multiplexage des broches. Dans le DT, les appareils qui ont besoin que les broches soient multiplexées d'une certaine manière doivent déclarer la configuration de contrôle des broches dont ils ont besoin.

Le sous-système pinctrl fournit :

Le multiplexage des broches, qui permet de réutiliser la même broche à des fins différentes, par exemple une broche étant une broche UART TX, une ligne GPIO ou Ligne de données HSI. Le multiplexage peut affecter des groupes de broches ou des broches individuelles.
Configuration des broches, appliquant les propriétés électroniques des broches telles que pull-up, pull-down, force du pilote, période de rebond, etc.

Le but de ce livre est limité à l'utilisation des fonctions exportées par le pilote du contrôleur de broche, et n'explique pas comment écrire un pilote de contrôleur de broche.

Pinctrl et l'arborescence des périphériques

Le pinctrl n'est rien d'autre qu'un moyen de rassembler des broches (pas seulement GPIO) et de les transmettre au pilote. Le pilote du contrôleur de broches est responsable de l'analyse des descriptions des broches dans le DT et de l'application de leur configuration dans la puce. Le pilote a généralement besoin d'un ensemble de deux nœuds imbriqués pour décrire les configurations de groupe de broches. Le premier nœud décrit la fonction du groupe (à quoi servira le groupe), le second contient la configuration des broches.

La façon dont les groupes de broches sont attribués dans le DT dépend fortement de la plate-forme, et donc du pilote du contrôleur de broches. Chaque état de contrôle de broche reçoit un ID entier commençant à 0 et contigu. On peut utiliser une propriété de nom, qui sera mappée au-dessus des identifiants, de sorte que le même nom pointe toujours vers le même identifiant.

La propre liaison de chaque périphérique client détermine l'ensemble d'états qui doit être défini dans son nœud DT, et s'il faut définir l'ensemble d'ID d'état qui doit être fourni, ou s'il faut définir l'ensemble de noms d'état qui doit être fourni. Dans tous les cas, un nœud de configuration des broches peut être affecté à un appareil au moyen de deux propriétés :

pinctrl- :Cela permet de donner la liste des configurations pinctrl nécessaires pour un certain état de l'appareil. Il s'agit d'une liste de phandles, dont chacun pointe vers un nœud de configuration de broche. Ces nœuds de configuration de broche référencés doivent être des nœuds enfants du contrôleur de broche qu'ils configurent. Plusieurs entrées peuvent exister dans cette liste afin que plusieurs contrôleurs à broches puissent être configurés, ou pour qu'un état puisse être construit à partir de plusieurs nœuds pour un seul contrôleur à broches, chacun contribuant à la configuration globale.
pinctrl-name :Cela permet de donner un nom à chaque état d'une liste. L'entrée de liste 0 définit le nom pour l'ID d'état entier 0, l'entrée de liste 1 pour l'ID d'état 1, et ainsi de suite. L'ID d'état 0 est généralement nommé default . La liste des états standardisés se trouve dans include/linux/pinctrl/pinctrl-state.h .

Ce qui suit est un extrait de DT, montrant certains nœuds de périphérique, ainsi que leurs nœuds de contrôle de broche :

Dans l'exemple précédent, une configuration de broche est donnée sous la forme . Par exemple :

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x80000000

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 représente la fonction de broche, qui est GPIO dans ce cas, et 0x80000000 représente les paramètres de broche. Pour cette ligne,

MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D25__UART3_RX_DATA représente la fonction de broche, qui est la ligne RX de UART3, et 0x1b0b1 représente ses paramètres.

La fonction pin est une macro dont la valeur n'est significative que pour le pilote du contrôleur pin. Ceux-ci sont généralement définis dans les fichiers d'en-tête situés dans arch//boot/dts/ . Si l'on utilise un quad UDOO, par exemple, qui a un quad core i.MX6 (ARM), l'en-tête de fonction de broche serait arch/arm/boot/dts/imx6q-pinfunc.h . Voici la macro correspondant à la cinquième ligne du contrôleur GPIO5 :

#define MX6QDL_PAD_DISP0_DAT11__GPIO5_IO05 0x19c 0x4b0 0x000 0x5 0x0

peut être utilisé pour configurer des éléments tels que des pull-ups, des pull-downs, des gardiens, la force d'entraînement, etc. La façon dont il doit être spécifié dépend de la liaison du contrôleur de broche et la signification de sa valeur dépend de la fiche technique du SoC, généralement dans la section IOMUX. Sur i.MX6 IOMUXC, seuls les bits inférieurs à 17 sont utilisés à cette fin.

Ces nœuds précédents sont appelés à partir du nœud spécifique au pilote correspondant. De plus, ces broches sont configurées lors de l'initialisation du pilote correspondant. Avant de sélectionner un état de groupe de broches, il faut d'abord obtenir le contrôle des broches à l'aide de la fonction pinctrl_get(), appeler pinctrl_lookup_state() afin de vérifier si l'état demandé existe ou non, et enfin pinctrl_select_state() pour appliquer l'état.

Ce qui suit est un exemple qui montre comment obtenir un pincontrol et appliquer sa configuration par défaut :

On effectue généralement de telles étapes lors de l'initialisation du pilote. L'endroit approprié pour ce code pourrait être dans la fonction probe().

pinctrl_select_state() appelle en interne pinmux_enable_setting() , qui à son tour appelle le pin_request() sur chaque broche du nœud de contrôle des broches.

Un contrôle de broche peut être libéré avec la fonction pinctrl_put(). On peut utiliser la version gérée par les ressources de l'API. Cela dit, on peut utiliser pinctrl_get_select(), étant donné le nom de l'état à sélectionner, afin de configurer pinmux. La fonction est définie dans include/linux/pinctrl/consumer.h comme suit :

static struct pinctrl *pinctrl_get_select(struct device *dev,
const char *name)

où *name est le nom de l'état tel qu'il est écrit dans la propriété pinctrl-name. Si le nom de l'état est default , on peut simplement appeler la fonction pinctr_get_select_default(), qui est un wrapper autour de pinctl_get_select() :

static struct pinctrl * pinctrl_get_select_default(
                                  struct device *dev)
   {
      return pinctrl_get_select(dev, PINCTRL_STATE_
}

Voyons un exemple réel dans un fichier dts spécifique à la carte (am335x-evm.dts ):

dcan1 :d_can@481d0000 {
       status =« OK » ;
       pinctrl-names =« par défaut » ;
       pinctrl-0 =<&d_can1_pins> ;
   } ;

Et dans le pilote correspondant :

pinctrl =devm_pinctrl_get_select_default(&pdev->dev);
if (IS_ERR(pinctrl))
dev_warn(&pdev->dev,"les broches ne sont pas configurées à partir du pilote" );

Le noyau de contrôle des broches réclamera automatiquement l'état pinctrl par défaut pour nous lorsque l'appareil est sondé. Si l'on définit un état d'initialisation, le noyau pinctrl définira automatiquement pinctrl sur cet état avant la fonction probe(), puis passera à l'état par défaut après probe() (à moins que le pilote n'ait déjà explicitement changé d'état).

Le prochain article traitera du sous-système GPIO.

John Madieu est un ingénieur Linux embarqué et noyau vivant en France, à Paris. Ses principales activités consistent à développer des drivers et des Board Support Packages (BSP) pour des entreprises dans des domaines tels que l'automatisation, les transports, la santé, l'énergie et l'armée. John travaille chez EXPEMB, une entreprise française pionnière dans la conception de cartes électroniques basées sur l'ordinateur sur module et dans les solutions Linux embarquées. C'est un passionné d'open source et de systèmes embarqués, convaincu que ce n'est qu'en partageant ses connaissances que l'on apprend plus.

Déploiement de solutions de sécurité IIoT Gestion de la sécurité IIoT

Technologie de l'Internet des objets

Embarqué

Capteur

Cloud computing

Technologie de l'Internet des objets