Date:	Sat, 3 Jan 2015 14:12:06 +0100
From:	Alexandre Courbot <gnurou@...il.com>
To:	Michael Welling <mwelling@...cinc.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"acourbot@...dia.com" <acourbot@...dia.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Roland Stigge <stigge@...com.de>,
	Wolfgang Grandegger <wg@...ndegger.com>, tstratman@...cinc.com,
	Rojhalat Ibrahim <imr@...chenk.de>
Subject: Re: Linux GPIO internals

Hi Michael, sorry for the delayed reply on this interesting issue.

On Wed, Dec 24, 2014 at 10:53 PM, Michael Welling <mwelling@...cinc.com> wrote:
> 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?

It seems like your mail is coming just at the right time. We have
recently merged a patch that allows setting several GPIOs at the same
time, if the hardware supports it:

http://patchwork.ozlabs.org/patch/406666/

It lacks sysfs support, but we are also increasingly feeling the
pressure of the old sysfs interface and are planning to develop a new
one:

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311158.html

Our main gripe with the old sysfs interface is its use of the
(potentially varying) integer GPIO namespace, and we would like one
that relies on the new gpiod_ functions. But while we are at it, we
could just as well support GPIO groups and try to make things faster,
although I am not sure why sysfs would be slower than a character
device.

On the top of my head, I think we could have an export interface that
allows to export a group of GPIOs under a given name, and to
manipulate them using gpiod_set/get_array(). Single GPIOs could be
exported as a group of 1.

I have looked at the EMAC GPIO class (very low level, and clearly tied
to a given subset of GPIO hardware), and anything that makes it
upstream would need to feature considerably more abstraction, but we
can certainly try to work something out.

Considering the constraints that we have (no GPIO integers for
exporting, sysfs-based, uses gpiod_*array()), do you think we could
satisfy your goals as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists