From: Konstantinos Margaritis <markos@codex.gr>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Mitch Bradley <wmb@firmworks.com>,
devicetree-discuss list <devicetree-discuss@ozlabs.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: GPIO - marking individual pins (not) available in device tree
Date: Tue, 28 Oct 2008 14:31:29 +0100 [thread overview]
Message-ID: <7b6eafc46f644dea59fbf0af17dbc005@localhost> (raw)
Pardon my intrusion in the conversation, but I just couldn't not comment on
this:
On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson
<david@gibson.dropbear.id.au> wrote:
>> So now my qualm is back to the beginning of the discussion. How do
>> we encode the purpose of those pins reliably and within some
>> standard framework, without getting *driver* specific?
>
> Um.. I fail to see how the purpose of a pin can be not driver
> specific.
GPIO stands for _General_ Purpose IO. The driver should just expose that
info to user space and it should be up to the userspace application to
decide what to do with that. The programmer should require absolutely
no other intervention to the driver whatsoever.
Anyone that has worked on data mining scientific equipment -eg.
particle/photon scanners on VME boards with lots of GPIO pins- will tell
you that meddling with kernel coding is totally unneeded, in fact it's
stupid to require the student to do so. Usually some Windows API is given
and the students write the programs on Windows to collect the data and
control the device. I guess GPIOLIB and the new framework would have
similar application in Linux -ie, requiring the programmer to write only
a userspace to access the GPIO pins. From my understanding of the
conversation, there are some people who fail to see the necessity of
doing extra work to abstract this information away from the driver. A walk
to a nearby experimental physicists lab with students working on such
devices will convince you of the right way to do it actually.
PS. I am of physics background myself, though a theoritical one and not
experimental. But I did have many friends experimentalists, in
particular I remember two that did exactly what I described. Neither did
have any particular kernel/driver knowledge and neither did have to do
anything extremely low-level to acquire the data. Both used windows
user-level programming, though that was ~8years ago so don't expect me
to remember the exact VME boards or APIs used...
Konstantinos Margaritis
Codex
http://www.codex.gr
next reply other threads:[~2008-10-28 13:31 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 13:31 Konstantinos Margaritis [this message]
2008-10-28 14:11 ` GPIO - marking individual pins (not) available in device tree Anton Vorontsov
2008-10-28 14:15 ` Grant Likely
2008-10-28 17:06 ` Matt Sealey
2008-10-28 17:32 ` Grant Likely
2008-10-28 23:37 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2008-10-23 21:32 Matt Sealey
2008-10-23 22:22 ` Mitch Bradley
2008-10-23 23:05 ` Matt Sealey
2008-10-24 0:52 ` Mitch Bradley
2008-10-24 3:29 ` David Gibson
2008-10-24 4:17 ` Mitch Bradley
2008-10-24 4:45 ` David Gibson
2008-10-24 22:14 ` Matt Sealey
2008-10-26 23:47 ` David Gibson
2008-10-27 15:40 ` Matt Sealey
2008-10-27 18:34 ` Anton Vorontsov
2008-10-27 18:56 ` Matt Sealey
2008-10-27 20:10 ` Anton Vorontsov
2008-10-27 21:56 ` Matt Sealey
2008-10-27 23:12 ` Anton Vorontsov
2008-10-27 23:40 ` Anton Vorontsov
2008-10-28 0:47 ` Matt Sealey
2008-10-28 1:11 ` Matt Sealey
2008-10-28 2:37 ` Anton Vorontsov
2008-10-28 16:53 ` Matt Sealey
2008-10-28 17:39 ` Grant Likely
2008-10-28 19:46 ` Matt Sealey
2008-10-28 0:15 ` David Gibson
2008-10-28 0:51 ` Matt Sealey
2008-10-28 1:50 ` David Gibson
2008-10-28 5:20 ` Grant Likely
2008-10-24 22:03 ` Matt Sealey
2008-10-24 22:20 ` Stephen Neuendorffer
2008-10-26 21:39 ` Matt Sealey
2008-10-24 23:44 ` Mitch Bradley
2008-10-26 21:13 ` Matt Sealey
2008-10-26 23:53 ` David Gibson
2008-10-27 16:12 ` Matt Sealey
2008-10-27 16:35 ` Scott Wood
2008-10-27 17:05 ` Matt Sealey
2008-10-27 17:25 ` Scott Wood
2008-10-27 17:49 ` Matt Sealey
2008-10-27 17:54 ` Scott Wood
2008-10-28 0:38 ` David Gibson
2008-10-28 0:34 ` David Gibson
2008-10-24 4:58 ` David Gibson
2008-10-24 3:27 ` David Gibson
2008-10-24 16:41 ` Anton Vorontsov
2008-10-24 17:01 ` Anton Vorontsov
2008-10-24 22:17 ` Matt Sealey
2008-10-24 22:37 ` Anton Vorontsov
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=7b6eafc46f644dea59fbf0af17dbc005@localhost \
--to=markos@codex.gr \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree-discuss@ozlabs.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=wmb@firmworks.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).