GPIO in the kernel: an introduction [LWN.net]

GPIO in the kernel: an introduction

Posted Jan 17, 2013 18:12 UTC (Thu) by dougg (guest, #1894)
In reply to: GPIO in the kernel: an introduction by linusw
Parent article: GPIO in the kernel: an introduction

Here is a view from the trenches of the Linux gpio subsystem, seen from the Atmel AT91 family, specifically the AT91SAM9x5 sub-family.

The biggest mistake was introduced initially: using a single sequence of kernel gpio numbers to represent a two level hierarchy. For example the AT91SAM9G20 has 3 banks: PA0-31, PB0-31 and PC0-31. For some crazy reason (something about not interfering with interrupt numbers) they mapped PA0 to 32 and the gpio numbers followed in sequence from there (hence PC31 is 127). Well sanity finally prevailed and around lk 3.5 they remapped PA0 to 0. Great, lots of user space code to rewrite.

And in lk 3.8.0-rc1 they were at it again. A gpio pin that had a sysfs name of /sys/class/gpio/gpio32 suddenly became /sys/class/gpio/pioB0 . Well that's a better name but why not use /sys/class/gpio/pb0 so as to agree with Atmel's naming (apart from capitalisation)?? And more user space code needs to be rewritten.

Back around lk 2.6.28 they removed a gpio pass-through driver leaving sysfs as (almost) the only way to get to gpios. I say almost because for serious work with AT91s mmap() is your friend. With luck in lk 3.9 we might get a well-designed block gpio driver so it will probably get vetoed or bowdlerized.

to post comments

GPIO in the kernel: an introduction

Posted Jan 18, 2013 23:58 UTC (Fri) by jimparis (guest, #38647) [Link]

It sounds like your concern is accessing GPIOs from userspace, but I thought the primary intended consumer of this particular ABI was kernel drivers, and that accessing GPIOs via /sys was intended just for debugging, in lieu of a proper driver for the hardware you're playing with.

Then again, Documentation/gpio.txt does claim that "for some tasks, simple userspace GPIO drivers could be all that the system really needs", which at least suggests that it should be considered a production API. So complaints about API breakes are probably worth bringing up when they happen.