GPIO character device next steps

GPIO character device next steps

[Linus Walleij]

As you know we froze the GPIO sysfs ABI in kernel v4.6 and
now we need to complete its replacement with a new mechanism
using the character device.

We can currently:

- Enumerate gpiochips - udev/systemd and its siblings
  will do this automatically from the character devices
  (a patch for mdev will be needed for BusyBox to enumerate
  the chips).

- List its lines with name and consumer strings, that is what
  "lsgpio" from tools/gpio/lsgpio.c does.

- Locate the offset of any desired GPIO line from this string

- Locate the gpiochip in the bus topology using sysfs
  (as with any device)

So I need some help, rants, ACKs etc on whatever I come up
with next, and the next steps are (from the top of my head):

- Naming GPIO lines from DT files
  (So you have something reasonable to look for from userspace)
  What do people think about just using
  gpio-names = "foo", "bar", "baz"; as suggested by Rob Herring?

- Getting a filehandle for one or several GPIOs
  I would prefer to support getting multiple GPIOs from day one
  as we know this is going to be a usecase sooner or later.
  For example it is not uncommon to bitbang a bus from userspace
  and then clock and data lines should

- Give them consumer names from userspace (label who's
  using this GPIO)

- Setting flags on a line from userspace (such as ACTIVE_LOW
  or OPEN_DRAIN) so the hardware can act accordingly.

- Using this filehandle, shake the lines from low to high and vice
  versa from userspace.

- Getting a filehandle to listen to input events (interrupts) from a
  certain GPIO line. Here I am primarily thinking about something
  akin to IIO's event mechanism using poll() which I like a lot.

- Getting the filehandle for events involves selecting trigger type
  for rising/falling edge events. (I don't see how userspace could
  possibly support or want to support level IRQs.)

I am thinking about using filehandles to get a grip on (multiple)
GPIOs and for events because it has the nice property that we
know very well when userspace is using the resource, and we can
free it when the file is closed (which also happens if the application
crashes or get killed, or at shutdown etc).

I'm thinking about staying with a single open() on the chardev
from userspace, but several processes can open handles, then
we need to use an ioctl() to say what we want from this
filehandle: whether a handle on a few GPIO lines or a polled
event.

We want to be mutually exclusive to processes when getting
pins for output, while making it possible for several clients
to read the same line or subscribe to events from the same
line.

Your thoughts?

Yours,
Linus Walleij

Re: GPIO character device next steps

[Jonathan Cameron]

On 08/04/16 19:32, Linus Walleij wrote:
> As you know we froze the GPIO sysfs ABI in kernel v4.6 and
> now we need to complete its replacement with a new mechanism
> using the character device.
Does it actually make sense to replace it?  Or rather extend
it via the chardev. I've not really been following the discussion
though if you've already addressed this.
> 
> We can currently:
> 
> - Enumerate gpiochips - udev/systemd and its siblings
>   will do this automatically from the character devices
>   (a patch for mdev will be needed for BusyBox to enumerate
>   the chips).
> 
> - List its lines with name and consumer strings, that is what
>   "lsgpio" from tools/gpio/lsgpio.c does.
> 
> - Locate the offset of any desired GPIO line from this string
> 
> - Locate the gpiochip in the bus topology using sysfs
>   (as with any device)
> 
> So I need some help, rants, ACKs etc on whatever I come up
> with next, and the next steps are (from the top of my head):
> 
> - Naming GPIO lines from DT files
>   (So you have something reasonable to look for from userspace)
>   What do people think about just using
>   gpio-names = "foo", "bar", "baz"; as suggested by Rob Herring?
Seems sensible to me.
> 
> - Getting a filehandle for one or several GPIOs
>   I would prefer to support getting multiple GPIOs from day one
>   as we know this is going to be a usecase sooner or later.
Absolutely.
>   For example it is not uncommon to bitbang a bus from userspace
>   and then clock and data lines should
> 
> - Give them consumer names from userspace (label who's
>   using this GPIO)
Useful to what?  What is going to read this info? (debugfs?)
> 
> - Setting flags on a line from userspace (such as ACTIVE_LOW
>   or OPEN_DRAIN) so the hardware can act accordingly.
> 
> - Using this filehandle, shake the lines from low to high and vice
>   versa from userspace.
> 
> - Getting a filehandle to listen to input events (interrupts) from a
>   certain GPIO line. Here I am primarily thinking about something
>   akin to IIO's event mechanism using poll() which I like a lot.
We don't support multiple listeners in IIO.  Maybe some combination
of that and evdev which spins off a separate fifo for each listener.
> 
> - Getting the filehandle for events involves selecting trigger type
>   for rising/falling edge events. (I don't see how userspace could
>   possibly support or want to support level IRQs.)
> 
> I am thinking about using filehandles to get a grip on (multiple)
> GPIOs and for events because it has the nice property that we
> know very well when userspace is using the resource, and we can
> free it when the file is closed (which also happens if the application
> crashes or get killed, or at shutdown etc).
> 
> I'm thinking about staying with a single open() on the chardev
> from userspace, but several processes can open handles, then
> we need to use an ioctl() to say what we want from this
> filehandle: whether a handle on a few GPIO lines or a polled
> event.
Perhaps use anonymous file handles for each case.  So the exposed
chardev is simply there for configuration of what others will do.
Then you can have an ioctl to get an anonymous file handle for each of
(with the appropriate description of what it is handling).

* Read multiple inputs
* Write multiple outputs
(for both of these are you distinguishing between cases where you an guarantee
they happen simultaneously and others where they are just close in time? 
Makes a huge difference in some cases obviously - such as reading from a parallel
ADC - or writing to a DAC).

* Events - though that could probably be shared with a read multiple inputs
chardev - or maybe not if it's about different pins...

Re reading above I guess you may already mean this by one file for multiple
things?  
> 
> We want to be mutually exclusive to processes when getting
> pins for output, while making it possible for several clients
> to read the same line or subscribe to events from the same
> line.
Are you thinking one file descriptor for one pin (for events) or
handling more complex registrations?  I can see the infrastructure
for this getting rapidly complex.

Could do it with irq_chips like we do in IIO triggers - so you can
have one irq fire multiple listening devices...

> 
> Your thoughts?
Good luck ;)

I've been thinking about how to handle logic analyzer type
inputs in IIO for a while.  One example is beaglelogic with it's around
100MHz sampling of 8 channels, It might be interesting to use some of
this same gpio infrastructure to play around with the ideas (though probably
not the actual beaglelogic data flows - that will need some large block transfer
tricks) - particularly once you have nice functions to feed sets of gpios
from arbitrary locations out on a read.

Clearly there would be some overlap, but I doubt you'll get into the
complexity of triggered captures etc here or at least not without jumping
to userspace and back again.  Some gpio chips do support this sort of 
sampling, but I suspect they aren't going to be found in many 'normal'
systems. (e.g. an input bank latch on event).

Anyhow, this was really just a request to keep any data handling/merging
infrastructure nicely separated from the front end bit spitting it out of
a chardev as there are/may be other usecases.

Jonathan

> 
> Yours,
> Linus Walleij
> 

Re: GPIO character device next steps

[Linus Walleij]

On Sun, Apr 10, 2016 at 5:16 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 08/04/16 19:32, Linus Walleij wrote:
>>
>> As you know we froze the GPIO sysfs ABI in kernel v4.6 and
>> now we need to complete its replacement with a new mechanism
>> using the character device.
>
> Does it actually make sense to replace it?  Or rather extend
> it via the chardev. I've not really been following the discussion
> though if you've already addressed this.

We're freezing it. It can be used in parallel for the foreseeable
future but the chardev is default-enabled in order to make people
prefer that, the sysfs (/sys/class/gpio) needs to be turned on
explicitly.

The sysfs is a sad story because it is completely stateless, i.e.
we have no clue of knowing if a userspace process is actually
alive and using a certain GPIO or not, there is nothing that closes
it down if the consumer dies etc.

>> - Give them consumer names from userspace (label who's
>>   using this GPIO)
>
> Useful to what?  What is going to read this info? (debugfs?)

Also lsgpio, also the kernel can print "I can's use GPIO n just
right now because a userspace consumer is using it for <string>"
we just chose the model to name both ends of the
GPIO line, the producer and the consumer. The producer and
consumer can both label their end.

Of course I could just hard-code all userspace consumers as
the string "userspace" if people prefer that.

>> - Getting a filehandle to listen to input events (interrupts) from a
>>   certain GPIO line. Here I am primarily thinking about something
>>   akin to IIO's event mechanism using poll() which I like a lot.
>
> We don't support multiple listeners in IIO.  Maybe some combination
> of that and evdev which spins off a separate fifo for each listener.

Yes people were talking about evdev as a good example of
how to do this. I will have to look into that code, it seems like
a good idea.

>> I'm thinking about staying with a single open() on the chardev
>> from userspace, but several processes can open handles, then
>> we need to use an ioctl() to say what we want from this
>> filehandle: whether a handle on a few GPIO lines or a polled
>> event.
>
> Perhaps use anonymous file handles for each case.  So the exposed
> chardev is simply there for configuration of what others will do.
> Then you can have an ioctl to get an anonymous file handle for each of
> (with the appropriate description of what it is handling).

Sounds about right. Can you point me to a place where anonymous
file handles are delivered out from the kernel?

> * Read multiple inputs
> * Write multiple outputs
>
> (for both of these are you distinguishing between cases where you an guarantee
> they happen simultaneously and others where they are just close in time?
> Makes a huge difference in some cases obviously - such as reading from a parallel
> ADC - or writing to a DAC).

What happens in practice is that if the back-end supports
the .set_multiple() callback, and it turns out that it can be
performed by a single register write or so, then it will happen
simultaneously. Else the kernel will issue individual .set()
calls.

We have no .get_multiple(). Maybe one day someone will
implement it :/

> * Events - though that could probably be shared with a read multiple inputs
> chardev - or maybe not if it's about different pins...
>
> Re reading above I guess you may already mean this by one file for multiple
> things?

I guess
one filehandle for reading n GPIOs
one filehandle for writing/toggling n GPIOs
one event filehandler for getting events from one GPIO

Each which will relase its GPIO[s] at close.

>> We want to be mutually exclusive to processes when getting
>> pins for output, while making it possible for several clients
>> to read the same line or subscribe to events from the same
>> line.
>
> Are you thinking one file descriptor for one pin (for events) or
> handling more complex registrations?  I can see the infrastructure
> for this getting rapidly complex.

No just one FD for one GPIO line for events. Else it's
going to get hopeless.

> Could do it with irq_chips like we do in IIO triggers - so you can
> have one irq fire multiple listening devices...

TBH I never quite wrapped my head around that forked irqchip
thing, it scares the living daylights out of me. Its like a virtual irqchip
and there it looses me.

> I've been thinking about how to handle logic analyzer type
> inputs in IIO for a while.

A logic analyzer seems like a pretty extreme case of general
purpose input, does it not?

> One example is beaglelogic with it's around
> 100MHz sampling of 8 channels, It might be interesting to use some of
> this same gpio infrastructure to play around with the ideas (though probably
> not the actual beaglelogic data flows - that will need some large block transfer
> tricks) - particularly once you have nice functions to feed sets of gpios
> from arbitrary locations out on a read.
>
> Clearly there would be some overlap, but I doubt you'll get into the
> complexity of triggered captures etc here or at least not without jumping
> to userspace and back again.  Some gpio chips do support this sort of
> sampling, but I suspect they aren't going to be found in many 'normal'
> systems. (e.g. an input bank latch on event).
>
> Anyhow, this was really just a request to keep any data handling/merging
> infrastructure nicely separated from the front end bit spitting it out of
> a chardev as there are/may be other usecases.

Hm I'll CC you on the patches when we get there and you can tell
me what to split out in its own .c/.h file :)

I can easily see people setting up systems that will use a bunch of
GPIOs alongside a bunch of sensors or DAC/ADCs so I hope for the
GPIO and IIO worlds to stay close.

Yours,
Linus Walleij

Re: GPIO character device next steps

[Jonathan Cameron]

On 10/04/16 16:53, Linus Walleij wrote:
> On Sun, Apr 10, 2016 at 5:16 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 08/04/16 19:32, Linus Walleij wrote:
>>>
>>> As you know we froze the GPIO sysfs ABI in kernel v4.6 and
>>> now we need to complete its replacement with a new mechanism
>>> using the character device.
>>
>> Does it actually make sense to replace it?  Or rather extend
>> it via the chardev. I've not really been following the discussion
>> though if you've already addressed this.
> 
> We're freezing it. It can be used in parallel for the foreseeable
> future but the chardev is default-enabled in order to make people
> prefer that, the sysfs (/sys/class/gpio) needs to be turned on
> explicitly.
> 
> The sysfs is a sad story because it is completely stateless, i.e.
> we have no clue of knowing if a userspace process is actually
> alive and using a certain GPIO or not, there is nothing that closes
> it down if the consumer dies etc.
Fair enough.
> 
>>> - Give them consumer names from userspace (label who's
>>>   using this GPIO)
>>
>> Useful to what?  What is going to read this info? (debugfs?)
> 
> Also lsgpio, also the kernel can print "I can's use GPIO n just
> right now because a userspace consumer is using it for <string>"
> we just chose the model to name both ends of the
> GPIO line, the producer and the consumer. The producer and
> consumer can both label their end.
> 
> Of course I could just hard-code all userspace consumers as
> the string "userspace" if people prefer that.
> 
>>> - Getting a filehandle to listen to input events (interrupts) from a
>>>   certain GPIO line. Here I am primarily thinking about something
>>>   akin to IIO's event mechanism using poll() which I like a lot.
>>
>> We don't support multiple listeners in IIO.  Maybe some combination
>> of that and evdev which spins off a separate fifo for each listener.
> 
> Yes people were talking about evdev as a good example of
> how to do this. I will have to look into that code, it seems like
> a good idea.
> 
>>> I'm thinking about staying with a single open() on the chardev
>>> from userspace, but several processes can open handles, then
>>> we need to use an ioctl() to say what we want from this
>>> filehandle: whether a handle on a few GPIO lines or a polled
>>> event.
>>
>> Perhaps use anonymous file handles for each case.  So the exposed
>> chardev is simply there for configuration of what others will do.
>> Then you can have an ioctl to get an anonymous file handle for each of
>> (with the appropriate description of what it is handling).
> 
> Sounds about right. Can you point me to a place where anonymous
> file handles are delivered out from the kernel?
Yup, do that in IIO for event chardevs.  See
drivers/iio/industrialio/industrialio-core.c iio_ioctl
> 
>> * Read multiple inputs
>> * Write multiple outputs
>>
>> (for both of these are you distinguishing between cases where you an guarantee
>> they happen simultaneously and others where they are just close in time?
>> Makes a huge difference in some cases obviously - such as reading from a parallel
>> ADC - or writing to a DAC).
> 
> What happens in practice is that if the back-end supports
> the .set_multiple() callback, and it turns out that it can be
> performed by a single register write or so, then it will happen
> simultaneously. Else the kernel will issue individual .set()
> calls.
Would be good to let userspace know if this can be done or not...
Otherwise 'weird' timing bugs are likely to confuse people.
> 
> We have no .get_multiple(). Maybe one day someone will
> implement it :/
> 
>> * Events - though that could probably be shared with a read multiple inputs
>> chardev - or maybe not if it's about different pins...
>>
>> Re reading above I guess you may already mean this by one file for multiple
>> things?
> 
> I guess
> one filehandle for reading n GPIOs
> one filehandle for writing/toggling n GPIOs
> one event filehandler for getting events from one GPIO
> 
> Each which will relase its GPIO[s] at close.
Sounds right.  Though a given userspace consumer may well use a
number of each of those..
> 
>>> We want to be mutually exclusive to processes when getting
>>> pins for output, while making it possible for several clients
>>> to read the same line or subscribe to events from the same
>>> line.
>>
>> Are you thinking one file descriptor for one pin (for events) or
>> handling more complex registrations?  I can see the infrastructure
>> for this getting rapidly complex.
> 
> No just one FD for one GPIO line for events. Else it's
> going to get hopeless.
Certainly fiddlier ;)
> 
>> Could do it with irq_chips like we do in IIO triggers - so you can
>> have one irq fire multiple listening devices...
> 
> TBH I never quite wrapped my head around that forked irqchip
> thing, it scares the living daylights out of me. Its like a virtual irqchip
> and there it looses me.
*laughs*  It's actually much simpler than you'd think.  We'd just ended
up implementing our own logic for handling making an interrupt do a whole
load of different things (registered by different drivers).

Arnd Bergman (IIRC) pointed out that the irq chip stuff does it already
so we switched over.  Was hairy in the early days because of stupid
restrictions on how many IRQs platforms would support, but I think that
has mostly gone away now.  Lots of MFD parts use them the same way these
days.
> 
>> I've been thinking about how to handle logic analyzer type
>> inputs in IIO for a while.
> 
> A logic analyzer seems like a pretty extreme case of general
> purpose input, does it not?
Yup - always target the extremes - it's more fun that way ;)
> 
>> One example is beaglelogic with it's around
>> 100MHz sampling of 8 channels, It might be interesting to use some of
>> this same gpio infrastructure to play around with the ideas (though probably
>> not the actual beaglelogic data flows - that will need some large block transfer
>> tricks) - particularly once you have nice functions to feed sets of gpios
>> from arbitrary locations out on a read.
>>
>> Clearly there would be some overlap, but I doubt you'll get into the
>> complexity of triggered captures etc here or at least not without jumping
>> to userspace and back again.  Some gpio chips do support this sort of
>> sampling, but I suspect they aren't going to be found in many 'normal'
>> systems. (e.g. an input bank latch on event).
>>
>> Anyhow, this was really just a request to keep any data handling/merging
>> infrastructure nicely separated from the front end bit spitting it out of
>> a chardev as there are/may be other usecases.
> 
> Hm I'll CC you on the patches when we get there and you can tell
> me what to split out in its own .c/.h file :)
Meh. Can always do it later if it makes sense - only have to get the userspace
right at this stage.
> 
> I can easily see people setting up systems that will use a bunch of
> GPIOs alongside a bunch of sensors or DAC/ADCs so I hope for the
> GPIO and IIO worlds to stay close.
Absolutely. Nothing the odd little bridge driver can't deal with as long
as we can put in the relevant bits to avoid jumping backwards and forwards
from userspace.

Anyhow, the really fun bit is seeing what horrendous userspace hacks
occur because we gave them the means to do crazy things ;)

Jonathan
> 
> Yours,
> Linus Walleij
>