Outside the Walled Garden

Am Freitag konnte ich ein weiteres Spielzeug in Empfang nehmen — PIXEL.

In der Selbstbeschreibung des Projektes auf Kickstarter ist PIXEL »An interactive LED based display for retro pixel art«. Der 20x20cm Rahmen besteht dabei aus einer Matrix von 32x32 LED-Pixeln, also 1024 in der Summe und einer Mikrokontroller-Platine zum Ansteuern der Pixel. Die Bilddaten selbst werden von einer Anwendung über Bluetooth übermittelt.

Nach einigen Startschwierigkeiten — der erste Bluetooth-Adapter wollte nicht mit meinem Telefon sprechen — funktioniert das ganze jetzt auch

Jetzt muss ich mir nur noch überlegen, was ich damit anstelle.

Nachdem die Erneuerung des Interrupt-Controllers ja nun abgeschlossen ist, folgt gleich das nächste Großprojekt — der DMA-Controller der S3C24XX-Prozessoren.

Was ist DMA

DMA steht für Direct Memory Access und soll helfen die Übertragung von Daten vom Arbeitsspeicher zu Geräten (und zurück) zu beschleunigen.

Der einfache Weg, Daten zwischen diesen auszutauschen nennt sich PIO — Programmed Input/Output. Dabei liest der Prozessor die zu übertragenden Daten häppchenweise aus dem Speicher und schreibt sie in spezielle Register des Gerätes. Gerade diese Häppchen-Arbeitsweise macht das ganze zum einen langsam und erfordert zum anderen auch eine ständige Beteiligung des Prozessors.

Hier setzt nun DMA an, indem es einen Kommunikationsweg zwischen Sender und Empfänger ohne Beteiligung des Prozessors bietet. Hier wird dem DMA-Controller nur noch mitgeteilt, welchen Speicherbereich er zu welchem Ziel übertragen soll. Nach dem Start der Übertragung hat der Prozessor mit dieser nichts mehr zu tun und kann andere Aufgaben erledigen. Nach dem Ende des Transfers wird er über einen Interrupt darüber benachrichtigt und kann dann an der entsprechenden Position weitermachen.

Aktueller Zustand

Wie bei fast allen anderen Subsystemen auch, gab es im ARM-Bereich auch bei den DMA-Controllern die Tendenz, dass jeder seine eigene Schnittstelle zwischen Gerätetreibern und DMA-Controllern kreierte — so ist der aktuelle DMA-Treiber der S3C24XX-Prozessoren in den Jahren 2003 bis 2006 entstanden — und seit dem auch nicht mehr großartig verändert worden.

In dieser Konstellation bieten natürlich nur Treiber DMA-Funktionalität, die speziell für diese Controller-Schnittstelle angepasst geschrieben wurden. Im ARM-Bereich ist dies oftmals möglich, da die Prozessoren meist spezielle Peripheriegeräte mitbringen die auch nur in diesen Prozessoren vorkommen. Schwierig wird es mit solchen privaten Schnittstellen dann, wenn sich wirklich mehrere Prozessoren dieselben Geräte teilen — so teilen sich die S3C24XX Prozessoren zum Beispiel einige wenige Geräte mit neueren Samsung-Prozessoren bis hin zum aktuellen Exynos.

DMAEngine

Seit 2006 hat sich aber auch das DMAEngine-Framework von Intel als die hardwareunabhängige Lösung für DMA-Transfers etabliert. Dort implementieren die Hardware-Treiber nicht mehr den gesamten Transfer sondern nur noch die wirklich hardwarespezifischen-Einstellungen des DMA-Controllers.

Interessanterweise gibt es zwar eine recht gute Dokumentation zur Nutzung der DMAEngine in Treibern, aber keine zum Schreiben von DMAEngine-Treibern. Es bleibt also beim Lesen von Code-Kommentaren um die Funktionsweise zusammen zu puzzeln.

Das Release des Kernel 3.9 nähert sich mit großen Schritten und wenn ich meinem Patch-Tracker glauben darf, wird der folgende 3.10 mein volumenstärkster Kernel bisher. Die dortige Statistik sagt mir:

• 48 individual patches
• 1832 lines added
• 1680 lines removed

Die 48 Patches sind also nochmal knapp 40% meiner bisherigen Kernel-Patches — schon cool. Im Einzelnen gehören dazu:

Die Restarbeiten der Interrupt-Umstellung, die ja bereits letztens erwähnt wurden (ARM: S3C24XX: irq rework for S3C2412, S3C2440 and S3C2442, ARM: S3C24XX: integrate special s3c2412 eint handling, ARM: S3C24XX: more fixes and enhancements for the s3c24xx irqs).

Die DeviceTree-Unterstützung für die Interrupt-Controller war dann doch nicht ganz so trivial und weckte etwas Diskussionsbedarf — wie an der Menge der Revisionen gut zu erkennen ist. Jetzt nach allen Änderungen muss ich aber auch sagen, dass die Devicetree-Syntax für die Interrupt-Controller deutlich besser gworden ist, als mein erster Versuch.

Der Rest ist dann im Vergleich dazu eher Kleinkram. Der Oyo-Display-Controller bekommt die Fähigkeit die Anzeige zu rotieren und den Anwendungen 16bit vorzugaukeln, da nicht alle Anwendungen mit einem palettenbasierten Display zurechtkommen. Der Oyo-Touchscreen bekommt Devicetree-Unterstützung. Und dann gibts da noch ein paar weitere Kleinigkeiten in anderen Teilen.

Nach Ladenschluss

Momentan läuft die vermutlich letzte Woche des Entwicklungszyklus von 3.9. Das heißt, alle Features für das Merge-Window von 3.10 müssen jetzt bereits linux-next erreicht haben. Leider bedeutet dies auch, dass einige meiner Patches erst für 3.11 in Frage kommen.

Dies sind der Pinctrl-Treiber für die Samsung S3C24xx SoCs und die generelle Devicetree-Unterstützung für den S3C2416.

Vor ein paar Tagen kam mit der Aufnahme in den Samsung-Maintainer-Tree mein bisher größtes Restrukturierungsprojekt der älteren Samsung-SoCs zu einem vorläufigen Ende. Im Kern ging es dabei um eine Neuordnung des Codes, der die Interrupt-Controller der S3C24XX-SoCs steuert, um später DeviceTree-Unterstützung für die S3C24XX-SoCs realisieren zu können — mehr zu DeviceTree folgt in einem späteren Eintrag.

Bisheriger Zustand

Die S3C24XX-SoCs verwenden zwar den selben Interrupt-Controller, dessen innere Struktur unterscheidet sich jedoch zwischen allen SoC-Varianten. Im Endeffekt handelt es sich »nur« um unterschiedlich belegte Bits in den Registern des Controllers. Zur Verdeutlichung ein kleines Beispiel:

Der S3C2410 signalisiert also in Bit 18 Interrupts des zweiten DMA-Kanals, während der S3C2416 dort Interrupts der vierten seriellen Schnittstelle signalisiert.

Implementiert war das Ganze dann derart, dass ein generischer Interrupt-Init die Struktur für den S3C2410 zusammenbaute und später dann eine SoC-spezifische zweite Init-Funktion, die geänderten Werte überschrieb. Diese zweite Funktion wurde über einen arch_initcall und damit zu einem gänzlich anderen Zeitpunkt gestartet.

Ein zweites großes Manko war die Festlegung auf statische Interrupt-Nummern. In arch/arm/mach-s3c24xx/include/mach/irqs.h waren den jeweiligen Interrupts feste Nummern zugewiesen und diese Nummern wurden auch durch den ganzen Interrupt-Code verstreut verwendet. D.h. es fanden sich überall Fragmente wie das folgende:

if (irq >= IRQ_EINT0 && irq <= IRQ_EINT3) ....

Dadurch kam es zu vielen Code-Dopplungen die sich nur in den verwendeten Interrupt-Nummern unterschieden.

Als drittes großes Problem ist noch das fehlen einer IRQ-Domain, welche aber für DeviceTree-Unterstützung absolut notwendig ist.

Der gesamte Prozess zog sich von Anfang November bis Ende Januar und große Teile davon entstanden auf den Flughäfen von Barcelone, Frankfurt und Hong Kong .

Neue Weltordnung

Nach dem Entfernen und Hinzufügen von 1132 respektive 688 Codezeilen stellt sich das System nun folgendermassen dar. Der gesamte Aufbau folgt nun einem deklarativen Ansatz. In einer speziellen Struktur werden die Parameter der Interrupt, also Typ und gegebenenfalls Eltern-Interrupt deklariert. Die mehrfach vorhandenen Funktionen zum quittieren, maskieren und demaskieren von Interrupts sind verschwunden und wurden durch einen einzigen Satz von Funktionen ersetzt, die ihr spezifisches Verhalten aus der Interrupt-Deklaration ableiten.

Ebenso wird jetzt für jeden der Subinterrupt-Controller eine IRQ-Domain erstellt und der vorherige zweistufige Init ist auch normalisiert.

Ausblick

Als Restarbeit müssen noch die S3C2412, S3C2440 und S3C2442 Varianten in die neue Struktur konvertiert werden. Nachdem das generelle Konzept aber angenommen wurde, ist dies nichtmehr allzu schwierig. Die eigentliche DeviceTree-Unterstützung im Interrupt-Code ist dann auch nur noch eine relativ kleine Änderung, die auch schon im Großen und Ganzen existiert und nur noch etwas Feinschliff benötigt.

Der dritte Tag begann mit einer Keynote »Research into Open Hardware«, d.h. Hardware bei der Informationen, Teilelisten etc frei verfügbar sind. Danach folgt die Veranstaltung, die vermutlich das Highlight der LinuxCon Europe war. Dirk Hohndel unterhielt sich mit Linus Torvalds über »Linux: Where are we going«. Der größte Vortragsraum war brechend voll, eine Menge Leute hatten noch nicht mal einen Sitzplatz gefunden und trotzdem saß ich ziemlich gut in der vierten Reihe.

Die Fragen aus dem Publikum sind in solchen Gesprächsrunden trotzdem immer sehr ähnlich. Natürlich kam die Frage zu NVidia, zu der Linus aber nur schmunzelnd meinte, diese wäre »exhaustively answered«. Auf die Frage ob es wirklich notwendig ist, große Teile der Kernel-Interna so oft umzubauen, meinte er, dass man doch lieber aktuelle Kernel »tracken« sollte, statt sich an alten Kernelversionen festzuklammern. Denn bei einem sehr großen Versionssprung ist der Update-Aufwand enorm, wenn man statt dessen immer direkt zwischen aufeinander folgenden Kernel-Veröffentlichungen updated, ist dies meist ziemlich schmerzfrei.

Aus meinen Erfahrungen mit dem Oyo-Kernel kann ich das bestätigen. Ich wechsle ja immer direkt zum jeweiligen -rc1. Dieses Update von der Vorgängerversion ist im Allgemeinen auch innerhalb von 1-2 Stunden abgeschlossen — je nachdem ob irgendwas größeres kaputt gegangen ist.

Die nächste Veranstaltung war dann »DRM/KMS, FB and V4L2«, ein grober Überblick über die verschiedenen Grafik-Subsysteme die der Kernel bereitstellt. Hier ergab sich für mich sogar mal eine Frage, nämlich ob sich ein protokollieren der veränderten Display-Bereiche im KMS-Subsystem ähnlich dem deferred-io in manchen Framebuffer-Treibern realisieren lässt. Es wäre mal interessant einen EPD-Treiber zu entwickeln, der KMS nutzt. Das Tracken der Bereiche sollte in der Theorie auch funktionieren, es hat nur noch nie jemand probiert.

Dann folgte mit »Regmap: The Power of Subsystems and Abstractions« eine Einführung in ebendieses System, dass hilft Zugriffe auf externe Register — zum Beispiel von I2C-Geräten — zu optimieren.

Die nächsten zwei Präsentationen beschäftigten sich mit »Low-Level Linux Debugging without Greay Beards« und »Debugging Embedded Linux (Kernel) Power Management«. Diese besondere Erkenntnis hier war, dass es keine besondere Erkenntnis gab — das heißt, ich wußte ungefähr wovon sie sprachen, habe nur Dinge am Rand als wirklich neu empfungen und demzufolge nur wenige Wissenslücken auf dem Gebiet.

Der letzte Vortrag des Tages war dann »UBI Fastmap«, der sich mit einer speziellen Ablagestruktur der Daten auf echtem Flash-Speicher beschäftigt. Während alle Geräte die ich momentan bebastele, entweder über SD-Karten oder eMMC-Speicher verfügen, war es trotzdem sehr interessant einen kleinen Einblick zu erhaschen wie man das Wear-leveling auf echten Flash-Speichern realisieren (und beschleunigen) kann. Ausserdem ist Thomas Gleixner, den ich ja am Vortag kennengelernt hatte, ein sehr unterhaltsamer sprecher.