From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] drivers: create a pin control subsystem v8
Date: Mon, 24 Oct 2011 13:05:18 +0200 [thread overview]
Message-ID: <20111024110518.GG8708@ponder.secretlab.ca> (raw)
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
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@secretlab.ca> 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. :-)
g.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>,
Linus Walleij <linus.ml.walleij@gmail.com>,
Stephen Warren <swarren@nvidia.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Barry Song <21cnbao@gmail.com>,
linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>,
Russell King <linux@arm.linux.org.uk>,
Linaro Dev <linaro-dev@lists.linaro.org>,
Lee Jones <lee.jones@linaro.org>,
David Brown <davidb@codeaurora.org>,
linux-arm-kernel@lists.infradead.org,
Stijn Devriendt <highguy@gmail.com>
Subject: Re: [PATCH] drivers: create a pin control subsystem v8
Date: Mon, 24 Oct 2011 13:05:18 +0200 [thread overview]
Message-ID: <20111024110518.GG8708@ponder.secretlab.ca> (raw)
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
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@secretlab.ca> 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. :-)
g.
next prev parent reply other threads:[~2011-10-24 11:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 12:03 [PATCH] drivers: create a pin control subsystem v8 Linus Walleij
2011-09-30 2:07 ` Grant Likely
2011-09-30 2:07 ` Grant Likely
2011-09-30 15:05 ` Linus Walleij
2011-09-30 15:05 ` Linus Walleij
2011-09-30 17:07 ` Grant Likely
2011-09-30 17:07 ` Grant Likely
2011-09-30 17:20 ` Linus Walleij
2011-09-30 17:20 ` Linus Walleij
2011-10-01 10:39 ` Linus Walleij
2011-10-01 10:39 ` Linus Walleij
2011-10-04 20:35 ` Grant Likely
2011-10-04 20:35 ` Grant Likely
2011-10-22 17:44 ` Mike Frysinger
2011-10-22 17:44 ` Mike Frysinger
2011-10-24 7:26 ` Linus Walleij
2011-10-24 7:26 ` Linus Walleij
2011-10-24 7:36 ` Grant Likely
2011-10-24 7:36 ` Grant Likely
2011-10-24 7:48 ` Linus Walleij
2011-10-24 7:48 ` Linus Walleij
2011-10-24 9:20 ` Mike Frysinger
2011-10-24 9:20 ` Mike Frysinger
2011-10-24 12:28 ` Linus Walleij
2011-10-24 12:28 ` Linus Walleij
2011-10-24 11:05 ` Grant Likely [this message]
2011-10-24 11:05 ` Grant Likely
2011-10-25 8:05 ` Tony Lindgren
2011-10-25 8:05 ` Tony Lindgren
2011-10-25 8:17 ` Grant Likely
2011-10-25 8:17 ` Grant Likely
2011-10-25 8:23 ` Mark Brown
2011-10-25 8:23 ` Mark Brown
2011-10-24 9:14 ` Mike Frysinger
2011-10-24 9:14 ` Mike Frysinger
2011-09-30 18:08 ` Stephen Warren
2011-09-30 18:08 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111024110518.GG8708@ponder.secretlab.ca \
--to=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.