From: Michael Welling <mwelling@emacinc.com>
To: gregkh@linuxfoundation.org, linus.walleij@linaro.org,
acourbot@nvidia.com, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, Roland Stigge <stigge@antcom.de>,
Wolfgang Grandegger <wg@grandegger.com>,
tstratman@emacinc.com
Subject: Linux GPIO internals
Date: Wed, 24 Dec 2014 15:53:53 -0600 [thread overview]
Message-ID: <20141224215352.GA26482@sysresccd> (raw)
All,
For years now EMAC has provided an out-of-tree series of class drivers
for accessing various devices. The EMAC GPIO class and character
interfaces predate the introduction of the gpiolib interface and have
been ported across several kernel versions.
http://wiki.emacinc.com/wiki/Using_the_EMAC_GPIO_Class
Recently we have come to the conclusion that continuing to provide
support for these drivers is getting out of hand. It was agreed that we
move away from our non-standard drivers and use mainstream drivers for our
newest products.
That being said, we would like to be able to provide the capabilities
of our old drivers but it is not the case with the current gpiolib
implementation.
Here are the major concerns that we have with the gpiolib implementation:
- There is no mechanism to provide simultaneous access to multiple
GPIOs from userspace.
- The sysfs interface seems to vastly slower than the character
interface and it is far more cumbersome to handle access from a
userspace C program.
It seems that the first concern was attempted to be addressed by the
following patch:
https://lkml.org/lkml/2012/12/23/66
It seems this effort dropped off the radar in January of 2013.
What happened to this patch?
As for the second issue, I am not sure how to resolve this and am open
to ideas. I have seen similar concerns in other subsystem that use the
sysfs interface.
IIO example:
http://www.spinics.net/lists/linux-iio/msg15344.html
Suggestions?
next reply other threads:[~2014-12-24 21:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-24 21:53 Michael Welling [this message]
2015-01-03 13:12 ` Linux GPIO internals Alexandre Courbot
2015-01-05 17:47 ` Michael Welling
2015-01-14 12:18 ` Linus Walleij
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=20141224215352.GA26482@sysresccd \
--to=mwelling@emacinc.com \
--cc=acourbot@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stigge@antcom.de \
--cc=tstratman@emacinc.com \
--cc=wg@grandegger.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).