Re: [PATCH v2] gpio: add userspace ABI for GPIO line information

[Grant Likely <grant.likely@xxxxxxxxxx>]

On Fri, Feb 19, 2016 at 11:25 AM, Linus Walleij
<linus.walleij@xxxxxxxxxx> wrote:
> On Fri, Feb 19, 2016 at 11:26 AM, Michael Welling <mwelling@xxxxxxxx> wrote:
>> On Fri, Feb 19, 2016 at 10:47:45AM +0100, Linus Walleij wrote:
>>> On Fri, Feb 19, 2016 at 10:46 AM, Michael Welling <mwelling@xxxxxxxx> wrote:
>>>
>>> > I am looking forward to see how the GPIOs will be modified from userspace.
>>> > The fact that single controllers can host hundreds of GPIOs is going to
>>> > make it an interesting problem.
>>> >
>>> > Do you have a sketch of how the accesses with be performed?
>>> > ioctl, read, write.
>>>
>>> No. Suggestions welcome. Looking at drivers/iio for inspiration.
>>>
>>
>> Well one thing I never liked about the iio userspace is the mixed API.
>> You have to use sysfs to setup buffered reads and character device for
>> the reads.
>>
>> I suppose individual GPIOs could be configured by simply calling
>> specific ioctls passing the (offset, value) as the argument.
>
> I think so too... I guess we can safely assume that only one
> userspace process will need to access a GPIO chip at the same
> time, and in case there'd be several of them, they have to
> mediate access through a daemon (as is already done with other
> things).
>
>> GPIO_EXPORT_LINE_IOCTL - Allocate the GPIO to userspace.
>
> I suspect this should take an argument with a list of
> GPIOs from the start, so you can request several GPIO
> lines, with flags. Requesting several lines makes it
> possible to use devm_gpiod_get_array() and handle
> a bunch of GPIOs similtaneously.
>
>> GPIO_SET_DIRECTION_IOCTL - Set GPIO direction.
>> GPIO_SET_VALUE_IOCTL - Set GPIO value.
>> GPIO_GET_VALUE_IOCTL - Get GPIO value.
>
> Those we probably need.
>
>> GPIO_SET_ACTIVE_IOCTL - Set GPIO active high/low.
>> GPIO_SET_OPEN_DRAIN_IOCTL - Set GPIO open drain.
>> GPIO_SET_OPEN_SOURCE_IOCTL - Set GPIO open source.
>
> Those need to be flags passed when exporting a line due
> to the nature of the GPIO driver subsystem. Also I don't think
> it makes sense to change any of these dynamically anyway,
> you set this up when requesting a line.
>
>> Then all exported GPIOs could be accessible using
>> read and write callbacks.
>
> The kernel will just take the gpio descriptors and manage
> them, it'll "just work" I think.
>
>> Handling interrupts may prove a little trickier.
>> The poll could be used on the character device but then there would have to
>> be a way to resolve which GPIO triggered the interrupt.
>
> Here I lean toward the IIO event interface, that if you want to
> monitor a GPIO line you should ask for an event file
> descriptor and select() it waiting for events in userspace,
> i.e. every such request comes with obtaining a new fd
> and watching it.

That seems overly heavyweight. It would be reasonable to select on a
single file descriptor, and then on read it will also return a bitmap
of which pin(s) actually raised the event.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html