Hi,
On Friday 19 February 2016 12:51:48 Linus Walleij wrote:
> On Fri, Feb 19, 2016 at 12:35 PM, <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > [Me]
> >> 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.
>
> Hm. I'm not familiar with how that works... I guess I just
> have to go and read the code.
>
> > 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).
>
> So the usecase that has been around the recent months is
> basically Arduino-type usecases, where you want a Linux
> SoC+board to be used for clever electronics prototyping
> (Internet of Things-yada yada thingofabobs).
>
> Those are by definition one-off kind of things, and people
> want to go around having to implement kernelspace stuff
> for their one-offs.
>
> Another typical example is industrial
> automation, PLCs. Those currently mmap() their GPIO
> address range to userspace and hammers them from
> there, because they think Linux GPIO suck and they
> rather break down the kernelspace/userspace barrier
> than try to fix it. (Whether this stance come from
> laziness, ignorance or plain "not my problem" attitude,
> I don't know.)
>
> Industrial automation with relays and shutter and
> valves and whatnot are probably better off in userspace
> than in kernelspace, a bunch of GPIO onebit reading
> and writing drivers in the kernel is not gonna be helpful.
> If it's something more complex like a sensor they should
> use IIO, if it's a LED then they should use that
> subsystem etc. But for all these binary things that
> are really dumb analog components, like relays doing
> something misc.
>
> A typical case is a PLC or lab board such as
> BeagleBone or 96board, where there is a number of
> GPIO lines, that all come out on the same identical
> header on the board (96board has this). Then you want
> to put an accessory on this header and access it from
> userspace. But you want it to work the same no matter
> whether it is SoC A or SoC B.
>
> So in order to satisfy that usecase, you need to look up
> the GPIO by name. And that mechanism is now in
> place, just that we need some DT bindings or board
> data to name the lines (it can currently be done using
> the char *names[] array in struct gpio_chip).
The gpio-hogging DT bindings still seem perfectly fine for me:
qe_pio_a: gpio-controller@1400 {
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;
line_b {
gpio-hog;
gpios = <6 0>;
output-low;
line-name = "foo-bar-gpio";
};
};
This could be something like this without hogging:
...
line_b {
gpios = <6 0>;
line-name = "foo-bar-gpio";
};
Best Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: This is a digitally signed message part.
