Zack's Kernel News
Improving GPIO Interrupt Handling
Jerome Brunet asked Linus Torvalds and a lot of other people for guidance on some patches he wanted to write. The problem was how to have general-purpose input/output (GPIO) controllers provide a working IRQ to all GPIOs simultaneously. GPIO is a physical pin on a chip, with no particular purpose hard-coded into it, except that it can be used for either input or output as desired by the code using it. The interrupt request (IRQ) is a hardware signal used to interrupt whatever's happening (in this case whoever's using the GPIO pin) and to make something else happen instead.
If the Linux kernel is not able to interrupt something when it needs to, then it can't do process context switching in a timely fashion, and the user experience gets choppier. Fine-grained context switching is a crucial part of the Linux kernel, and uninterruptible operations are ideally always kept to a minimum.
Many hardware chips, Jerome said, had no trouble providing working IRQs to all GPIOs simultaneously. But some, like the Amlogic system on a chip (SoC), had trouble, because they didn't have enough IRQs available to match the number of GPIO pins.
To handle these cases, there would have to be some code to handle the GPIO resource properly, for example by manually associating particular interrupts with particular GPIOs on the fly. However, Jerome didn't like this possibility for a couple of reasons. For one thing, the mechanism for doing it was itself not interruptible, so the benefit to context switching was decreased. For another thing, once the code made the association between an interrupt and a GPIO, there was no corresponding mechanism to free up that association. It would just hang around even if it wasn't used anymore. So as Jerome put it, "this approach leaks mappings." He also pointed out that there were already quite a number of GPIO drivers using this approach, which indicated even more strongly that some kind of solution should be found.
Another solution, he said, was "to create an empty domain to get a virq for each pin but delay the setup of the interrupt hierarchy to the 'irq_request_resources' callback. Testing this approach led me to some nasty race conditions in the interrupt handlers. I discussed this solution with Marc [Zyngier] and he told me that doing the setup of the interrupt hierarchy in the irqchip callbacks is 'too late'."
Given the problems with each of these possibilities, Jerome felt there was no clean solution at the moment. He offered a third alternative that would require a fair bit of implementation. First, he would define a pair of prepare/unprepare functions, which any given GPIO driver could implement if needed. He would also add new functions to the GPIO kernel API that would implement reference counting in order to share scarce IRQs among multiple GPIOs. Finally, he'd go back to existing GPIO user code in the kernel and update them to use the new interface.
He emphasized that the new approach would be a complete no-op for any drivers that didn't need it. But for those that did, it would provide the working IRQs to all GPIOs simultaneously.
Linus Walleij, Grygorii Strashko, and Marc Zyngier immediately dove into a technical implementation discussion with Jerome, with various strong objections and new directions proposed. Ultimately, there was absolutely no consensus reached. But it's clearly something a lot of people care about, because it means the difference between cleanly supporting Linux on a piece of hardware, or not.
Zack Brown
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.