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

[Markus Pargmann <mpa@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3801 bytes --]

Hi,

On Friday 19 February 2016 12:51:48 Linus Walleij wrote:
> On Fri, Feb 19, 2016 at 12:35 PM,  <jic23@jic23.retrosnub.co.uk> 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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]