Re: [PATCH] drivers: create a pin control subsystem v8

[Tony Lindgren]

* Grant Likely <grant.likely@xxxxxxxxxxxx> [111024 12:31]:
> On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> > On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> > > On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> > (...)
> > >> I was more thinking along the lines of one device per GPIO controller,
> > >> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
> > >
> > > And there is also the question of whether it is even a good idea to
> > > export pinctrl manipulation to userspace.
> > 
> > The application I've seen is in automatic control.
> > 
> > I think people do things like connect they GPIO pins to electrical
> > relays, plus on top of that they use all the stuff in drivers/staging/iio.
> > 
> > All that from userspace. Controlling entire factories and industrial
> > robots, weapon systems too, I'm afraid.
> > 
> > The control of these dangerous things runs on a realtime-patched
> > kernel, in a single userspace app with a few threads and they have
> > done some realtime-tetris scheduling the beast more or less
> > manually with SCHED_FIFO. Basically that app is all that runs on
> > the board, and its threads take precedence over everything else
> > on the system.
> > 
> > That is the typical beast that is poking around on the GPIO sysfs
> > interfaces...
> 
> ... which maybe should be encouraged to use some form of uio driver.  :-)

Changing pins from userspace is extremely handy for debugging drivers
and PM. For normal use case there should not be any need except to
view the values.

But for debugging we should have some interface for changing
the values either via debugfs or some user space program.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/