GPIO - marking individual pins (not) available in device tree

[Matt Sealey]

Grant Likely wrote:
> 
> For Matt's purposes, I think he wants to describe which GPIO pins are
> available to be used, but are not yet connected to anything.  In such
> a case I think it does make sense to add a node for available GPIO
> pins and give it a gpios property with a list of the pins wired to the
> header.

Yes, the two problems I saw were there is only an implicit definition
of which gpios are available for use (GPIOLIB will happily give
you an unavailable pin if you ask for it, because there is no
definition except for "gpios" property as hooked up to a device).

I liked Mitch's idea about the available property and re-using already
existing standards and parsing to get it done.

(this allows some syntax/lint checking of a device tree too since if
you put a pin in a gpios property which you marked as unavailable,
you can flag it :)

The other problem was defining pins which most definitely ARE
connected to something (as GPIO) but could well be in an ill-defined
order or for no defined purpose with regards to the peripheral. A
lot of GPIO drivers right now (bitbang SPI, I2C) will just allocate
one pin as one thing and the other as another - if you say pin 15
and 16 for bitbang-i2c, then it may assumes pin 15 is clock and 16
is data. For SPI, you get another pin, which order is it (the
middle one may be correct but the outer ones could be swapped).

Is this even defined? Shouldn't it be? And therein lies the
question :)

Exposing it to userspace is a good idea. While grouping them up
would break the existing sysfs ABI there's no reason you can't
have all of the GPIOs dumped into sysfs as it is now, and then
new directories named after the gpio-group, which symlink back
to the sysfs pins in the parent directory? That would really
rock as it's bringing the abstraction and description of the
device tree back into userspace, where let's be honest, they do
not give a crap about device tree bindings, only what pin does
what action :D

-- 
Matt Sealey <matt at genesi-usa.com>
Genesi, Manager, Developer Relations