LWN: Comments on "GPIO in the kernel: future directions"

GPIO in the kernel: future directions

bokr — Thu, 14 Nov 2013 13:40:54 +0000

I wonder, have the SELinux people commented on the security aspects?

[BTW: the server behind the marc.info link seems to serve a page with missing <html> and <body> tags at the front]

when things are exposed to userspace, the bock based api is needed more

dlang — Fri, 25 Jan 2013 19:59:04 +0000

am I correct in thinking that the grouping capability would ease things and make it so that this could be done without SCHED_FIFO?

when things are exposed to userspace, the bock based api is needed more

zlynx — Fri, 25 Jan 2013 18:29:25 +0000

The timing and preemption problem is why I used SCHED_FIFO when I wrote a user-space front-panel LCD driver for an embedded system, long ago.

The program runs SCHED_OTHER as normal, then escalates into SCHED_FIFO at prio 95 (something like that) to program the data ports, then falls back.

I know that kernel interrupts and similar things may interfere but it was never a problem in practice. The LCD's timing requirements were not overly strict, just that you couldn't go away and ignore it for tens of milliseconds.

GPIO in the kernel: future directions

linusw — Fri, 25 Jan 2013 10:44:51 +0000

Thanks a lot for good commentary above.

One issue raised by Alan Cox concerns security, see this post:
http://marc.info/?l=linux-kernel&m=135489945103388&...

How are people feeling about this? I for one worry that we implement security problems that will be hell to fix further down the road.

GPIO in the kernel: future directions

dlang — Thu, 24 Jan 2013 19:50:37 +0000

if you are using the GPIOs to control a stepper motor directly, you can accept delay in making changes, but you _really_ want to have all the changes happen at the same time.

There is also the chance that changing multiple bits at once is much easier than changing one bit at a time.

If you were to use a parallel printer port as a GPIO (it has 8 outputs and 3 inputs IIRC), it's much easier to change all 8 bits at once than to change one bit at a time.

The only thing I find questionable with the concept is that it allows grouping GPIO lines that do not have any underlying connection, but that doesn't make things any worse than they are now (other than possibly fooling the programmer into thinking they are better than they are now), and the improvements in the code of things using GPIO lines can be significant.

one place this would make a huge amount of sense from a software point of view is if you are connected to a small LCD display through a parallel interface (very common for 16 character x 2 line displays for example).

with this interface, you can do

nibble = *c & 0x0F;
output(nibble);
toggle(clock);
nibble = *c++ <<4 & 0x0F;
output(nibble);
toggle(clock);

it would be much more work if you had to set each line independently.

GPIO in the kernel: future directions

jimparis — Thu, 24 Jan 2013 18:12:45 +0000

I think dlang's post above was not pointing out concerns with the grouped/block interface, but instead pointing out how it solves real problems.

There are lots of cases where you want things to happen simultaneously, but they're not time critical. For example, let's say you drive an RGB LED on a cell phone with three GPIOs. If it's currently yellow (R+G) and you want to change it to blue (B), you want to turn off two GPIOs and set one GPIO as a single operation. It's okay if the entire action is delayed by 250ms, but it's not okay to change one bit, then have a delay, then change the other two bits, because then you'll have a visibly long period with an unexpected third color.

GPIO in the kernel: future directions

linusw — Thu, 24 Jan 2013 14:02:15 +0000

Thanks Jon, excellent overview.

I have (as GPIO co-maintainer) raised my concerns about the new grouped GPIO sysfs API, and left it for Grant to decide upon. I can live with it, but I'm not overly happy with this ABI/API having to be perpetually supported.

My main concern is about use cases and I really haven't seen anybody step up and say: "I use this for X, Y, and Z". If that X, Y and Z is a fan on a laptop, a LED and some CD tray opener then yeah OK. But that does not seem to be the case, as the entire basis for its existence is that it be time-critical.

For example, and related to the concerns that dlang raise above: what if these GPIO lines are controlling the servo motor of some robot, a dialysis machine or a fighter jet?

I have hear RUMORS about this kind of use cases. That people will stick a process in userspace which is basically dealing with automatic control somekindof. And it's time critical, so the system is basically just running this one process, and it is elevated to real-time priority, so starvation etc should not occur.

If you have the new SCHED_DEADLINE you could maybe do things like this (obviously this is done from userspace):
http://www.youtube.com/watch?v=UJSWvC-QnjI

I don't know if this kind of things are what we're designing for with our sysfs interface, and I feel slightly inconvenient not knowing. Please use the comment field here to tell us all about your plans for userspace GPIO.

when things are exposed to userspace, the bock based api is needed more

dlang — Thu, 24 Jan 2013 03:06:16 +0000

When userspace attempts to bit-bang multiple lines at the same time, you have the added problem that the userspace app may be preempted (potentially for a significant period of time), and this makes reliable operation much harder.

It also means that the reliability degrades significantly as the load goes up. This will mean that it may never fail when the developer is testing it, but in teh real-world with higher load (and much longer operational periods) failures are almost guaranteed to take place.

If you try to group together GPIO lines that are on different hardware, you aren't going to be perfectly reliable, but in most cases, the GPIO lines really are grouped on the hardware level, non-uncommonly, to the point where some layer is reading the state of a bank of lines, modifying it based on what's requested, and writing the new state out to all the lines at once.

P.S. has anyone made a shim layer to allow you to use a parallel port as a set of GPIO lines?