Linux-Gerätetreiberentwicklung:Das Subsystem zur Pinsteuerung

Anmerkung der Redaktion:Der eingebettete Linux-Kernel spielt bereits eine wichtige Rolle in eingebetteten Systemen und wird bei der Erfüllung der vielfältigen Anforderungen des Internets der Dinge (IoT) an Bedeutung gewinnen. Gerätetreiber wiederum stellen die kritische Verbindung zwischen Anwendungen und IoT-Geräten selbst her. In der Entwicklung von Linux-Gerätetreibern bietet der Autor John Madieu einen umfassenden Einblick in die Entwicklung dieser Treiber und kombiniert detaillierte Erklärungen mit zahlreichen Codebeispielen.

Dieser Auszug, Kapitel 14 des Buches, konzentriert sich auf die Pinsteuerung und GPIOs – ein Bereich, der für Entwickler von eingebetteten Systemen von besonderer Bedeutung ist, die mit benutzerdefinierten Hardwaregeräten interagieren möchten. Dieser erste Teil dieses Auszuges stellt das Pin-Control-Subsystem vor.

Angepasst an die Entwicklung von Linux-Gerätetreibern von John Madieu.

---

Kapitel 14. Pin-Steuerung und GPIO-Subsystem
Von John Madieu

Die meisten Embedded-Linux-Treiber- und Kernel-Ingenieure schreiben mit GPIOs oder spielen mit Pin-Multiplexing. Mit Pins meine ich die Ausgangsleitung der Komponente. SoC verwendet Multiplex-Pins, was bedeutet, dass ein Pin mehrere Funktionen haben kann, z normales GPIO.

Der Mechanismus, mit dem man den Modus wählt, mit dem ein Pin arbeiten soll, wird Pin-Muxing genannt. Das dafür zuständige System heißt Pin-Controller. Im zweiten Teil des Kapitels werden wir die Allzweck-Eingabeausgabe . besprechen (GPIO ), das ist eine spezielle Funktion (Modus), in der ein Pin arbeiten kann.

In diesem Kapitel werden wir:

• Gehen Sie durch das Pinsteuerungs-Subsystem und sehen Sie, wie man ihre Knoten in DT deklarieren kann

• Entdecken Sie sowohl ältere ganzzahlbasierte GPIO-Schnittstellen als auch die neue deskriptorbasierte Schnittstellen-API

• Umgang mit GPIO, das dem IRQ zugeordnet ist

• Sysfs-Schnittstellen für GPIOs behandeln

Pin-Steuerungs-Subsystem

Die Pin-Steuerung (pinctrl )-Subsystem ermöglicht die Verwaltung von Pin-Muxing. Im DT müssen Geräte, die auf eine bestimmte Weise gemultiplexte Pins benötigen, die benötigte Pin-Steuerungskonfiguration deklarieren.

Das pinctrl-Subsystem bietet:

• Pin-Multiplexing, das die Wiederverwendung desselben Pins für verschiedene Zwecke ermöglicht, z. B. als UART-TX-Pin, GPIO-Leitung oder HSI-Datenleitung. Multiplexing kann sich auf Gruppen von Pins oder einzelne Pins auswirken.

• Pin-Konfiguration, die elektronische Eigenschaften von Pins wie Pull-Up, Pull-Down, Treiberstärke, Entprellzeit usw. anwendet.

Der Zweck dieses Buches beschränkt sich auf die Verwendung von Funktionen, die vom Pin-Controller-Treiber exportiert wurden, und erklärt nicht, wie man einen Pin-Controller-Treiber schreibt.

Pinctrl und der Gerätebaum

Pinctrl ist nichts anderes als eine Möglichkeit, Pins (nicht nur GPIO) zu sammeln und an den Treiber zu übergeben. Der Pin-Controller-Treiber ist dafür verantwortlich, Pin-Beschreibungen im DT zu parsen und ihre Konfiguration im Chip anzuwenden. Der Treiber benötigt normalerweise einen Satz von zwei verschachtelten Knoten, um Gruppen von Pin-Konfigurationen zu beschreiben. Der erste Knoten beschreibt die Funktion der Gruppe (wofür die Gruppe verwendet wird), der zweite enthält die Pin-Konfiguration.

Wie Pin-Gruppen im DT zugewiesen werden, hängt stark von der Plattform und damit vom Pin-Controller-Treiber ab. Jedem Pin-Steuerungszustand wird eine ganzzahlige ID zugewiesen, die bei 0 beginnt und zusammenhängend ist. Man kann eine name-Eigenschaft verwenden, die auf IDs abgebildet wird, sodass derselbe Name immer auf dieselbe ID zeigt.

Die eigene Bindung jedes Clientgeräts bestimmt die Menge der Zustände, die in ihrem DT-Knoten definiert werden müssen, und ob die Menge der bereitzustellenden Zustands-IDs oder die Menge der bereitzustellenden Zustandsnamen definiert werden soll. In jedem Fall kann einem Gerät ein Pin-Konfigurationsknoten über zwei Eigenschaften zugewiesen werden:

• pinctrl- :Dies ermöglicht die Liste der pinctrl-Konfigurationen, die für einen bestimmten Zustand des Geräts benötigt werden. Es ist eine Liste von Phandles, von denen jedes auf einen Pin-Konfigurationsknoten zeigt. Diese referenzierten Pin-Konfigurationsknoten müssen untergeordnete Knoten des Pin-Controllers sein, den sie konfigurieren. In dieser Liste können mehrere Einträge vorhanden sein, sodass mehrere Pin-Controller konfiguriert werden können oder ein Zustand aus mehreren Knoten für einen einzelnen Pin-Controller erstellt werden kann, die jeweils einen Teil der Gesamtkonfiguration beitragen.

• pinctrl-name :Dies ermöglicht es, jedem Staat in einer Liste einen Namen zu geben. Listeneintrag 0 definiert den Namen für die ganzzahlige Zustands-ID 0, Listeneintrag 1 für die Zustands-ID 1 und so weiter. Der Zustands-ID 0 wird üblicherweise der Name Standard gegeben . Die Liste der standardisierten Zustände finden Sie in include/linux/pinctrl/pinctrl-state.h .

Das Folgende ist ein Auszug aus DT, der einige Geräteknoten zusammen mit ihren Pin-Steuerungsknoten zeigt:

Im vorherigen Beispiel wird eine Pin-Konfiguration in der Form angegeben. Zum Beispiel:

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x80000000

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 repräsentiert die Pin-Funktion, in diesem Fall GPIO, und 0x80000000 repräsentiert die Pin-Einstellungen. Für diese Zeile,

MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D25__UART3_RX_DATA repräsentiert die Pin-Funktion, die die RX-Leitung von UART3 ist, und 0x1b0b1 repräsentiert seine Einstellungen.

Die Pin-Funktion ist ein Makro, dessen Wert nur für Pin-Controller-Treiber von Bedeutung ist. Diese sind im Allgemeinen in Header-Dateien definiert, die sich in arch//boot/dts/ befinden. Wenn man beispielsweise ein UDOO-Quad verwendet, das einen i.MX6-Quad-Core (ARM) hat, wäre der Pin-Funktionsheader arch/arm/boot/dts/imx6q-pinfunc.h . Das folgende Makro entspricht der fünften Zeile des GPIO5-Controllers:

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

kann verwendet werden, um Dinge wie Klimmzüge, Klimmzüge, Keeper, Antriebsstärke usw. einzurichten. Wie er angegeben werden sollte, hängt von der Pin-Controller-Bindung ab, und die Bedeutung seines Wertes hängt vom SoC-Datenblatt ab, im Allgemeinen im Abschnitt IOMUX. Beim i.MX6 IOMUXC werden zu diesem Zweck nur weniger als 17 Bit verwendet.

Diese vorhergehenden Knoten werden vom entsprechenden treiberspezifischen Knoten aufgerufen. Außerdem werden diese Pins während der entsprechenden Treiberinitialisierung konfiguriert. Vor der Auswahl eines Pin-Gruppenstatus muss zuerst die Pin-Steuerung mit der Funktion pinctrl_get() abgerufen werden, pinctrl_lookup_state() aufgerufen werden, um zu überprüfen, ob der angeforderte Status existiert oder nicht, und schließlich pinctrl_select_state(), um den Status anzuwenden.

Das Folgende ist ein Beispiel, das zeigt, wie man ein Pincontrol erhält und seine Standardkonfiguration anwendet:

Normalerweise führt man solche Schritte während der Treiberinitialisierung durch. Der geeignete Platz für diesen Code könnte innerhalb der probe()-Funktion sein.

pinctrl_select_state() ruft intern pinmux_enable_setting() auf, das wiederum pin_request() an jedem Pin im Pin-Steuerungsknoten aufruft.

Ein Pin-Control kann mit der Funktion pinctrl_put() freigegeben werden. Man kann die ressourcenverwaltete Version der API verwenden. Das heißt, man kann pinctrl_get_select() verwenden, wenn der Name des auszuwählenden Zustands gegeben ist, um pinmux zu konfigurieren. Die Funktion ist in include/linux/pinctrl/consumer.h wie folgt definiert:

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

wobei *name der Zustandsname ist, wie er in der Eigenschaft pinctrl-name geschrieben ist. Wenn der Name des Zustands default ist, kann man einfach die Funktion pinctr_get_select_default() aufrufen, die ein Wrapper um pinctl_get_select() ist:

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

Sehen wir uns ein echtes Beispiel in einer Board-spezifischen dts-Datei (am335x-evm.dts ) an:

dcan1:d_can@481d0000 {
       status ="okay";
       pinctrl-names ="default";
       pinctrl-0 =<&d_can1_pins>;
   };

Und im entsprechenden Treiber:

pinctrl =devm_pinctrl_get_select_default(&pdev->dev);
   if (IS_ERR(pinctrl))
       dev_warn(&pdev->dev“,Pins werden nicht vom Treiber konfiguriert“);

Der Pin-Kontrollkern wird automatisch den Standard-Pinctrl-Status für uns beanspruchen, wenn das Gerät untersucht wird. Wenn man einen init-Zustand definiert, wird der pinctrl-Kern automatisch pinctrl in diesen Zustand vor der probe()-Funktion setzen und dann nach probe() in den Standardzustand wechseln (sofern der Treiber nicht bereits explizit den Zustand geändert hat).

Der nächste Teil wird das GPIO-Subsystem besprechen.

Nachdruck mit Genehmigung von Packt Publishing. Copyright © 2017 Packt Publishing

---

John Madieu ist ein Embedded-Linux- und Kernel-Ingenieur, der in Frankreich in Paris lebt. Seine Haupttätigkeit besteht in der Entwicklung von Treibern und Board Support Packages (BSP) für Unternehmen in Bereichen wie Automatisierung, Transport, Gesundheitswesen, Energie und Militär. John arbeitet bei EXPEMB, einem französischen Unternehmen, das ein Pionier im elektronischen Board-Design basierend auf Computer-on-Module und in Embedded-Linux-Lösungen ist. Er ist ein Enthusiast von Open Source und eingebetteten Systemen, davon überzeugt, dass man nur durch das Teilen von Wissen mehr lernt.