Re: Linux GPIO internals

[Michael Welling <mwelling@xxxxxxxxxxx>]

On Sat, Jan 03, 2015 at 02:12:06PM +0100, Alexandre Courbot wrote:
> Hi Michael, sorry for the delayed reply on this interesting issue.
> 
> On Wed, Dec 24, 2014 at 10:53 PM, Michael Welling <mwelling@xxxxxxxxxxx> 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/
>

This looks like a good starting point. Being able to access to multiple
GPIOs simultaneously on the same controller bank is great.

What is nice about the EMAC class is that the GPIOs do not necessarily
have to be on the same bank (or controller) to be grouped together. The
system call overhead of accessing a single IO is the same as multiple
IOs in the same group.

Still wondering what happened to the gpioblock patch.

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

The with the migration from the legacy GPIO namespace it only seems
natural for the sysfs interface to follow. Adding groups in the process
would provide most of what is needed.

The sysfs interface is great for command line and scripting languages
but it has more overhead. It requires string conversion at both the
kernel and userspace. More system calls are typically required for
similar transactions.

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

This sounds good. Currently we group the IOs with devicetree
registrations.

http://git.emacinc.com/source/linux-at91.git/blob/linux-3.10-at91/arch/arm/boot/dts/ipac-9x25.dts#L226

It would be nice if it were possible to create the groups from
userspace.

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

I am more worried about standardizing EMAC's code base than pushing our
old code into the mainline.

> 
> 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?

This should be satisfactory for most use cases. I will try to support
efforts toward modernizing the sysfs interface.

Would a character interface to gpiolib ever be considered? 
--
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