linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?


             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).