LWN: Comments on "GPIO in the kernel: an introduction"

GPIO in the kernel: an introduction

jem — Mon, 18 Feb 2019 09:38:13 +0000

I do think the author is still using LWN.net. :) But he may be busy with other things.

GPIO in the kernel: an introduction

Circuits — Wed, 13 Feb 2019 16:51:56 +0000

Great information! Too bad this post was made in 2013 cause I have some questions here in 2018. Is the author or another authority still using LWN.net?

GPIO in the kernel: an introduction

asmo — Mon, 13 Feb 2017 10:36:13 +0000

Hi,
I need to use the same GPIO output in two different drivers.
Is it possible to use the set of apis gpio_request/gpio_get_value/gpio_set_value in parallel in both device drivers?

GPIO in the kernel: an introduction

flussence — Sat, 17 Dec 2016 06:44:15 +0000

Fun trivia: this is exactly what the NES Classic does. In their GPL code dump there's a kernel driver for the controller - it has the same wire protocol the Wiimote uses (internally!), but leaves the kernel to deal with all that hardware-related insanity and more.

GPIO in the kernel: an introduction

pizza — Thu, 15 Dec 2016 20:32:11 +0000

But hardware debounce would require adding extra $0.02 worth of components and growing your board size by 2 square millimeters.

Why spent that money on every unit when it can be done once, "for free" in software?

GPIO in the kernel: an introduction

BlueLightning — Thu, 15 Dec 2016 20:05:27 +0000

Surely the answer to switch bounce is to do the debouncing in hardware?

GPIO in the kernel: an introduction

bla — Thu, 15 Dec 2016 11:07:11 +0000

Ok, you c a n set a combined interrupt mask and query the pin state in the ISR on an RPi, but gpio_get_value seems to have latency, which makes this approach pretty much useless in conjunction with switch bounce and the ISR time constraints.
For implementing long button presses, detecting the first flank and reading the level with a thread after some delay seems to be the better approach, it also doesn't require a state change to trigger the long press signal.

GPIO in the kernel: an introduction

bla — Tue, 13 Dec 2016 19:11:08 +0000

Ah, probably a gpio-controller/IRQ line limitation. I'll check if it works on a Raspberry (should, as Wiring has a BOTH option).

GPIO in the kernel: an introduction

nybble41 — Tue, 13 Dec 2016 18:28:34 +0000

> Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

Things may be different on ARM or x86, but in my work on embedded PowerPC targets I have yet to see an interrupt controller than can be configured to trigger on both rising and falling edges for the same signal. Typically there are four possible trigger modes, of which only one can be active at a time: rising edge, falling edge, high level, or low level.

GPIO in the kernel: an introduction

bla — Tue, 13 Dec 2016 16:46:51 +0000

Why wouldn't IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING with request_irq work?

GPIO in the kernel: an introduction

nybble41 — Tue, 13 Dec 2016 14:56:02 +0000

> Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

The ISR will only run on the rising edge _or_ the falling edge, not both, so gpio_get_value will generally return a known result: either high for a rising-edge-triggered interrupt, or low for falling-edge.

GPIO in the kernel: an introduction

bla — Tue, 13 Dec 2016 14:20:54 +0000

Anything speaking against using gpio_get_value in the isr to discern between rising and falling?

GPIO in the kernel: an introduction

annonch — Mon, 03 Oct 2016 22:58:49 +0000

Wow thank you for the suggestion, it seems to work perfectly! I have configured an additional pin fed with the same signal and I think this method will work well for my project. :)

GPIO in the kernel: an introduction

nybble41 — Mon, 03 Oct 2016 19:27:50 +0000

> Is it possible to register an interrupt to both falling edge and rising edge and then distinguish which case it is inside the interrupt handler?

Generally speaking, no. I'm not familiar with your specific platform, but typically one configures the interrupt controller to look for either a rising edge or a falling edge (or low/high level) for each input and it generates a single interrupt when that event occurs. As a result, there is no way to statically configure it to watch for both rising and falling edges.

You could try dynamically reconfiguring the interrupt—set it as falling-edge in the rising-edge handler, and vice-versa—but performance would probably become an issue and you might miss some events depending on how long the handler is delayed. A better option, if you control the wiring and have a spare interrupt-capable GPIO, would be to route the same signal to two separate pins and set up a handler for each pin, one rising-edge and one falling-edge.

GPIO in the kernel: an introduction

annonch — Mon, 03 Oct 2016 19:12:34 +0000

Is it possible to register an interrupt to both falling edge and rising edge and then distinguish which case it is inside the interrupt handler?

When I try to register two interrupts I get an error resource is busy, I think because it is the same irq_number (-16)

When I try to register the interrupts with the IRQF_SHARED | IRQF_TRIGGER_RISING flags I get Invalid argument (-22)

So I create a interrupt with flags IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING but when the interrupt is called, I want to distinguish the two conditions separately.

It is an arm device with kernel 4.4.21

Any advice? :)

GPIO in the kernel: an introduction

mjg59 — Wed, 20 Jul 2016 08:05:56 +0000

They're EXPORT_SYMBOL_GPL - make sure that your MODULE_LICENSE tag is GPL compatible.

GPIO in the kernel: an introduction

codename_y — Wed, 20 Jul 2016 07:52:34 +0000

Hi, I have tried to make a driver that utilize linux/gpio.h, but when I try to insmod it, I keep getting this error:

[ 3030.112044] gpiotest: Unknown symbol gpio_direction_output (err 0)
[ 3030.118537] gpiotest: Unknown symbol gpio_request (err 0)

Could you give me some insight about why this happened? I have tried to find by myself but no luck so far.

Thanks for your help

GPIO in the kernel: an introduction

BenHutchings — Mon, 28 Jan 2013 21:27:53 +0000

1. GPIO can be both output and input at the same time. Yep you may want to read back the value of an output.

Indeed this is an absolute requirement for a GPIO used as an I2C SCL line.

GPIO in the kernel: an introduction

etienne — Mon, 21 Jan 2013 11:36:37 +0000

>> #define IOWRITE32BITS(addr, val) *((volatile unsigned *)(addr)) = (val)
> The volatile should ensure that both writes occur in that case.

Last time I tried few days ago it did not work, you have to do:
#define IOWRITE32BITS(addr, val) do { \
volatile unsigned *ptr = (volatile unsigned *)(addr); \
*ptr = (val); \
} while (0)

> You lose control over the access size

Yes, I would also like to have bitfields accessed like they are declared, i.e. "char abit : 2;" accessed as a byte and "unsigned abit :2;" accessed as a 32 bits, because it is usual to have devices which cannot do short word access (lots of system on chip).

> [... using "(struct my_IO_s) {}" extension ...]

My system is more complex than Arduino, I have arrays of structures containing other arrays in these I/O areas, and all those #define blessed by software-quality people drive me mad.
#define FPGA1_FILTER_2_PARAMETER_4_ACTIVE 1
How to do a loop for each filters?
In short, in C or C++, unlike BASIC, the linker is made to manage addresses, the compiler manages offsets into these addresses; the C pre-processor has nothing to do there.
IHMO even GPIO in the kernel shall be identified with an address, not a #define.

GPIO in the kernel: an introduction

jimparis — Sat, 19 Jan 2013 00:33:14 +0000

Also those quality specialists tell you to use the macro:
#define IOWRITE32BYTE(addr, val) *((volatile unsigned *)(addr)) = (val)
(Hint: try to write the same addr twice with a newer compiler).

The volatile should ensure that both writes occur in that case.

Anyway on newer architecture, those are memory mapped and IHMO it is a lot cleaner to use C to declare them:
volatile struct my_IO_s {
enum { healthy, fail } power_state : 1;
unsigned power_active : 1;
} * const my_IO = (volatile struct my_IO_s *)0xDC002000;
Instead of pages and pages of #define.

I agree, and I do the same in embedded development, but it's not perfect. The three biggest problems:

You lose control over the access size. It can vary between compilers, compiler versions, architectures, and even ABIs for particular architectures. For example, see GCC bug #23623

They don't map well to unusual registers. Consider an interrupt flag register which behaves like:

    read 0: interrupt has not occurred
    read 1: interrupt has occurred
    write 0: no action
    write 1: clear interrupt flag

To clear a flag, you can't just do:

    my_IO->timer_interrupt = 1;

because this can become

    tmp = *my_IO_addr | (1 << TIMER_INTERRUPT_SHIFT);
    *my_IO_addr = tmp;

Instead, you'd need to use something like:

    *my_IO = (struct my_IO_s) {
        .timer_interrupt = 1
    };

which is not much better than the equivalent:

    *my_IO_addr = (1 << TIMER_INTERRUPT_SHIFT);

Even for a more normal register like a GPIO port, it's quite difficult to set two bits simultaneously with a single write. You can't do:
```
    *my_IO_addr |= (1 << PIN0_SHIFT) | (1 << PIN1_SHIFT);
```
without something like:
```
   struct my_IO_s tmp = *my_IO;
   tmp.pin0 = 1;
   tmp.pin1 = 1;
   *my_IO = tmp;
```

Really it's one of the more annoying parts of C when doing embedded development on a constrained system, as it's hard to avoid without adding some layer of performance-killing indirection (like Arduino does).

GPIO in the kernel: an introduction

jimparis — Fri, 18 Jan 2013 23:58:31 +0000

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.

GPIO in the kernel: an introduction

dougg — Fri, 18 Jan 2013 14:42:47 +0000

To your second and third points, welcome to pinctrl introduced in lk 3.7 and 3.8 . And while you are at it, look at the device tree stuff (aka "open firmware" and hence lots of "of_" adorned names). gpio pin states can and should be set before the Linux kernel gets a look in (e.g. in uboot or earlier), and when it does the kernel should resist the temptation to set those lines to some arbitrary state.

Things are moving so fast in the device tree/pinctrl area that it might be worth LWN writing another article on the subject.

GPIO in the kernel: an introduction

kvaml — Fri, 18 Jan 2013 14:20:25 +0000

Just in time to help with my new Raspberry Pi. Thanks.

GPIO in the kernel: an introduction

etienne — Fri, 18 Jan 2013 11:50:06 +0000

> GPIO can be both output and input at the same time

Reading back output GPIO is described in Documentation/gpio.txt
My main problem is that people (even software manager responsible of software "quality") do think it is clean to use the C preprocessor, either in C or C++.
That leads to massive amount of #define, to define the address, the value when active, the value when inactive, the shift position for each GPIO and the mask for that GPIO (you never know if the mask is shifted or not).
Then you have a set of GPIO to represent a 3 bit value, and the preprocessor will never tell you that you are trying to write 0x15 in this 3 bit value.
Also those quality specialists tell you to use the macro:
#define IOWRITE32BYTE(addr, val) *((volatile unsigned *)(addr)) = (val)
(Hint: try to write the same addr twice with a newer compiler).
Anyway on newer architecture, those are memory mapped and IHMO it is a lot cleaner to use C to declare them:
volatile struct my_IO_s {
#ifdef BIG_ENDIAN
enum { healthy, fail } power_state : 1;
unsigned power_active : 1;
#else
unsigned power_active : 1;
enum { healthy, fail } power_state : 1;
#endif
} * const my_IO = (volatile struct my_IO_s *)0xDC002000;
Instead of pages and pages of #define.

GPIO in the kernel: an introduction

russell — Fri, 18 Jan 2013 08:44:05 +0000

Everyone thinks GPIO is easy, and that probably explains why the interfaces are incomplete. GPIO usually has a lot more functionality than can be accessed.

1. GPIO can be both output and input at the same time. Yep you may want to read back the value of an output. MCUs I've used in the past offered this. After all output are really just stronger versions of the pull up/down :)

2. GPIO have pull up/down resistors.

3. And this is the BIG one. GPIO has state BEFORE the kernel boots. Bootstrap code can set the state of GPIO during the first few cycles of operation. This can eliminate the need for extra external hardware. However, the kernel blows this away and you have to wait for userspace to boot before you get control!!!! This behaviour on for example RPi required extra hardware to be added to the circuit to prevent this kind of transient boot behaviour from glitching relays.

GPIO in the kernel: an introduction

zuki — Thu, 17 Jan 2013 21:08:34 +0000

Frankly I don't see the point of such a stub of an article. It would be better to have all three instalments now, and nothing for two weeks, then to be teased like that.

GPIO in the kernel: an introduction

dougg — Thu, 17 Jan 2013 18:12:03 +0000

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.

GPIO in the kernel: an introduction

corbet — Thu, 17 Jan 2013 13:05:38 +0000

That's a little embarrassing...and I rechecked all those prototypes. Fixed, thanks.

GPIO in the kernel: an introduction

notti — Thu, 17 Jan 2013 11:25:53 +0000

I think you missed the value in the gpio_set_value function

GPIO in the kernel: an introduction

linusw — Thu, 17 Jan 2013 09:19:55 +0000

Fun that you're diggin into this Jon, I have just had a presentation for the ELC accepted where I try to give an overview of recent changes in GPIO and pinctrl.