Jason R Thorpe <thorpej@wasabisystems.com>  wrote:
 > Soon I'm going to start work on a generic interface for manipulating
 > GPIO pins.  I'm still trying to figure out exactly what it should have,
 > but let me give you an idea of what I'm thinking about so far:
 > 
 > 	* When a device (e.g. a generic GPIO facility in an
 > 	  I/O processor) wishes to publish its GPIO pins to
 > 	  the world, it requests one or more chunks of GPIO
 > 	  "pin number" space from the GPIO framework.  A mapping
 > 	  is then established, e.g. "gpio pin 3 -> i80321 gpio pin 3"
 > 	  or "gpio pin 5 -> sc520 gpio pin 9".
 > 
 > 	  It's worth mentioning that I'm not entirely happy with
 > 	  either the dynamic nature of the assignment (what if it
 > 	  changes when you add a device?) nor with the fact that
 > 	  the mapping might not necessarily be 1 -> 1, 2 -> 2, etc.
 > 	  Although, this won't happen unless your system has more
 > 	  than one device that wants to publish its GPIO pins.
 > 
 > 	  There needs to be some way to mark pins as being "off limits",
 > 	  as well.  For example, on the i80321, if you're using I2C,
 > 	  2 of the GPIO pins are unavailable, because they're used for
 > 	  the I2C signals by the on-chip I2C controller.

Does there also need to be some way of marking pins as specifically input
or output?  ie: some processors have bi-directional I/O but some are
unidirectional after some configuration register is setup and you 
programmatically configure the direction of the pins.  Will userland
have access to that configuration register or is it assumed that the
implementation of the hardware is set in stone once the machine has been
ported to.  I think I'm just rambling now. Sorry.

 > 	* There will be a kernel API for manipulating the pins.  I was
 > 	  thinking along these lines:
 > 
 > 		struct gpio_pin {
 > 			int gpio_pin;
 > 			int gpio_value;
 > 		};
 > 
 > 		#define	GPIO_DIR_IN	0
 > 		#define	GPIO_DIR_OUT	1
 > 
 > 	  int gpio_get_val(struct gpio_pin *pins, int npins);
 > 	  int gpio_set_val(struct gpio_pin *pins, int npins);
 > 	  int gpio_toggle_val(struct gpio_pin *pins, int npins);
 > 	  int gpio_get_dir(struct gpio_pin *pins, int npins);
 > 	  int gpio_set_dir(struct gpio_pin *pins, int npins);

The icing on the cake would be some sort of uploadable filter language
that can define a state machine implemented by the kernel. Then it'd
be a no-brainer to build an SPI filter... Or, say, a BDM filter that
gets attached to the PC Parallel port GPIO driver.  Shouldn't be
too hard to put a vhdl parser in the kernel. :-)

Anyway, good on you. This is cool.