Re: Linux GPIO internals

On Mon, Jan 5, 2015 at 6:47 PM, Michael Welling [off-list ref] wrote:

On Sat, Jan 03, 2015 at 02:12:06PM +0100, Alexandre Courbot wrote:

quoted

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.

It's intended to handle the case when several GPIOs can be
switched at the same time by a single register write. It implies
being on the same controller.

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.

You're comparing pears and apples now I think.

A userspace ABI making it possible to switch several GPIOs
on several controllers is perfectly doable both with and without
the above interface.

In this latter case you're more worried about the latency
incurred by the userspace/kernelspace switch, whereas
the former is about the delays incurred by several register
writes.

Userspace/kernelspace switch delay is a few magnitudes
larger than the delay between sequenced register writes I
suspect.

Still wondering what happened to the gpioblock patch.

Roland?

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.

Agree. I have a problem with it too.

quoted

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?

I like the character interface idea actually.

/dev/gpiochip0
/dev/gpiochip1
(...)

Then ioctl() operations to do all the magic to figure out what GPIOs
are there and how to read/write them etc. To me this reflects the
system properly and gives all kind of freedom to manipulate the
GPIOs with efficient context switches. Plus we can deliberately
avoid including any GPIO numbers anywhere, just allow names
and nothing else.

But I'm no userspace/kernelspace expert, let's hear what
the linux-api mailing list has to say.

Yours,
Linus Walleij