Extending the GPIO framework

[mlelstv%serpens.de@localhost (Michael van Elst)]

The current gpio(4) framework supports simple I/O pins, you
can define a pin as input or output and select some common
hardware features like software-controllable pullup resistors.

Once defined, you can only read the state of an input pin or
set an output pin to low or high. But once defined, there is
no way to reconfigure the pins, for example to reverse
the direction or disable an output (in a secure kernel).


Some hardware can re-use the GPIO pins for different functions.
The gpio(4) framework allows other drivers to reserve pins
that are then no longer available for GPIO. But there is
no way to control this in a running system except by loading
and unloading driver modules... assuming you support modular
drivers and again don't use a secure kernel.


A small extension to the gpio framework would help in solving either problem.

Add an additional capability flag to each pin that allows changing
the pin configuration.

#define GPIO_PIN_CHANGE         0x00008000      /* allow reconfiguration */

This would be a flag controlling the framework like GPIO_PIN_SET.
A pin with this capability can be reconfigured. Usually this would
mean that possible changes are arbitrary, but the driver could
limit the capability bits when a pin is configured to those that
can actually be updated.


Add additional capability flags to each pin to make alternate
functions available. E.g.

#define GPIO_PIN_FUNC1          0x00010000      /* set function 1 */
#define GPIO_PIN_FUNC2          0x00020000      /* set function 2 */
#define GPIO_PIN_FUNC3          0x00040000      /* set function 3 */
#define GPIO_PIN_FUNC4          0x00080000      /* set function 4 */
#define GPIO_PIN_FUNC5          0x00100000      /* set function 5 */
#define GPIO_PIN_FUNC6          0x00200000      /* set function 6 */
#define GPIO_PIN_FUNC7          0x00400000      /* set function 7 */
#define GPIO_PIN_FUNC8          0x00800000      /* set function 8 */

A driver can implement these flags, possibly overriding or augmenting
the other GPIO_PIN flags.

The number of possible functions is limited by the number of flag bits,
but I haven't seen a device supporting a large number of alternate functions
per pin to make this a problem. Using the flag bits has the advantage
that it requires no changes to the gpio drivers that do not implement
alternate functions.

Alternate functions can be mapped to arbitrary hardware, it might be
interesting to identify this hardware using configurable names instead
of function numbers. This either requires a different interface or
some separate lookup function that maps names to a capability mask.

Like GPIO_PIN_{INPUT,OUTPUT,INOUT} the function selection is ambigous
in what combination of such configurations will actually do. Most
hardware probably requires to select only a function or I/O mode.


Comments?



-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."