On Mon, Oct 24, 2011 at 03:48, Linus Walleij wrote:
On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely 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...
we all agree that GPIO from userspace makes sense. the only complaint i've seen so far against the GPIO sysfs interface that should be addressed is the performance overhead.
but the question here is about pinctrl. does userspace really need to manipulate the pinmapping ? if we agree on that, then the question is on the userspace interface.
assuming we want this, i can't see the performance argument being made here for pinctrl. which means doing a sysfs interface here like we already have with GPIO makes the most sense. GPIO deals in "binary" data for the most part (reading/writing 0/1 ints) so the string-based sysfs parsing is a bit weird, but pinctrl deals with strings everywhere for selecting mapping groups, so sysfs is the natural answer. -mike