On 19.02.2016 11:25, Linus Walleij 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.
On events, it might be worth doing it a bit more input evdev
like and allowing mor than one consumer.
Do we need to describe to userspace what GPIOs are available?
Right now I don't have a board to hand to see what info is
already available on that front. Strikes me as that side of
things may be more complex than the interface to actually get hole
of them. It's this side of things that makes IOCTLs on highly
varied devices a pain (any why we ended up with the split interface
in IIO which is sort of an input / hwmon hybrid).
Jonathan
Yours,
Linus Walleij
--
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
