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

[Matt Sealey]

Anton Vorontsov wrote:
> The GPIO spec doesn't specify a controller bank. It says
> 
> - - - -
> gpio-specifier may encode: bank, pin position inside the bank,
> whether pin is open-drain and whether pin is logically inverted.
> - - - -
> 
> May encode. Or may not encode. FYI, for most (all) SOC GPIO
> controllers we don't use "bank" encoding in the gpio-specifier.

This is exactly 100% precisely why I asked about it, there should at
least be a binding for each specific controller where this is
relevant, but since there is very little variation on "use pin 15
please with these flags" (only what "pin 15" means is undefined
so far, and left to the driver/controller variation) there must
be a generic way to specify groups of IO pins which may not be
consecutive.

I don't get your example;

 > device {
 >	gpios = <&gpio 0 0 &gpio 1 0 &gpio 2 0>;
 > }
 >
 > ^^ Three gpios, 0, 1, 2. Based on a compatible entry Linux can
 >   translate them in any way.
 >
 >   For example GPIO0 - bit 15, GPIO1 - bit 20, GPIO2 - bit 1.

This kind of defeats the object. While the pin numbering may well
be board-specific, it makes sense to maintain it as it relates to
offsets into a register or offsets into a bank of registers the
same way that interrupt mappings on the MPC5200B are ripped out of a
table in the MPC5200B documentation.

What the above example does is give a completely arbitrary
number which only maps to a real pin or offset *inside the driver*
meaning 10 boards with the same chip all have to have different
drivers, gpio_chip libraries to allocate the pins - the driver
to note which pin is for which purpose, and gpiolib to make sure
some driver accessing them has not been loaded twice.

Right?

Even if I have my Efika sitting here I want to share my GPIO
library code between it and the lite5200b - be that making the
"sleep switch" code look for a certain gpio pin marker in the
device tree so it knows what to allocate (so the number isn't
hardcoded into the driver as a compile-time switch or a check
for the /soc node model)

The current model seems to me like it is not getting any benefit
whatsoever from being defined in a device tree, in fact it is
making certain GPIO functionality go back to the hardcoded-per-board
stuff we used to have in arch/ppc.

This is just proving the point that nobody is forward-thinking
about this stuff, and is just implementing hack over hack over
hack to get something to work, and refining it later. We're
already running kernels which need to be specially built for
specially built U-Boot versions, special options for the dtc,
and device trees which change every other week. Specifying the
bare minimum here for the functionality a single user uses
defeats the object of having a descriptive device tree.

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