Thread (17 messages) 17 messages, 6 authors, 2011-10-25

[PATCH] drivers: create a pin control subsystem v8

From: Grant Likely <hidden>
Date: 2011-10-25 08:17:31
Also in: lkml

Possibly related (same subject, not in this thread)

On Tue, Oct 25, 2011 at 10:05:32AM +0200, Tony Lindgren wrote:
* Grant Likely [off-list ref] [111024 12:31]:
quoted
On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
quoted
On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely [off-list ref] wrote:
quoted
On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
(...)
quoted
quoted
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.
I've got no issue with a debugfs interface, although it would probably
a good idea to put a big scary warning into klog when userspace starts
manipulating pinctrl setting.  Maybe should taint the kernel too.
Anything manipulating pinctrl, even more than gpio, *really* needs to
know what it is doing.  I'm not worried about hacking around when
doing board bringup and debug, but I'm all for barriers to actual
applications using it.

.... of course this also assumes that users have an easy to use
alternative that isn't as scary as exposing all of pinctl to
userspace.

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help