Linux GPIO internals

[Michael Welling <mwelling@xxxxxxxxxxx>]

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?

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html