At Tue, 13 Aug 2002 04:10:53 +0000 (UTC), "Jason R Thorpe" wrote:
> 	* 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);

Err, what do these do?  Get and set, OK, I understand, ... but
"toggle"?!

pulse?  "how wide?"  These things, and more, are important to people
who fiddle with GPIOs!  8-)

often, in my experience, you think you want
transition-wait-transition, but you don't.  (that assumes that you
know what state you're currently in.)  often (e.g. for resets, etc.)
you want "transition to this state, wait a little bit, transition to
this other state."  i.e., "go to 0, wait, go to 1", regardless of the
current setting.  (otherwise you need to do: set to 0, toggle... by
which time, you're better off just having been done set to 0, wait,
set to 1.  8-)


> 	  int gpio_get_dir(struct gpio_pin *pins, int npins);
> 	  int gpio_set_dir(struct gpio_pin *pins, int npins);

people have e.g. selectable debounce circuits on gpios, it would be
good to support that kind of thing.  (hehe.)


> 	* There will also be some kind of API for saying "interrupt
> 	  when this GPIO input pin does something" (configurable
> 	  for level or edge), but I haven't really thought too much
> 	  about how to handle that yet.  In particular, what IPL
> 	  do folks think GPIO pins should be registered at?  Should
> 	  they get a new IPL_GPIO (and splgpio())?

hmm.

(1) is this meant to be an internal API which people can use to
    control GPIOs used by other drivers?

    "Psst!  hey, buddy, lemme show you my generic bus IDE interface!"
    8-)

    If so, well, those should use the appropriate (& minimum) levels.

    For others, i dunno...  new, or ... tty?  Looks like a serial line
    to me.  8-)

(2) fun things with resource conflicts: sometimes, GPIOs can only be
    set in pairs to interrupt!

    need to be sure to document that, really, you definitely sohuld
    check those return values!

(3) edge / level setup.  input sense (high, low) too.


> 	* There'll also be a userland API, which takes two forms:
> 
> 		- An ioctl-based API that looks a lot like the
> 		  kernel API.
> 
> 		- A /dev/gpioN, where N == pin number, which is meant
> 		  for easy frobbing by scripts.  The idea is to do:
> 
> 			echo '1' > /dev/gpio0	# turn pin on
> 			echo '0' > /dev/gpio0	# turn pin off
> 			echo 't' > /dev/gpio0	# toggle pin
> 
> 		  Similarly, reading will return a '1' or '0', indicating
> 		  the current state.
> 
> 		  This would allow e.g. easy frobbing of an LED on
> 		  an embedded system, setting an error LED if booting
> 		  failed, etc.
> 		
> 		  This idea from Jasper Wallace.

hmm.

things come to mind:

* what if you've got multiple (call 'em a flock!) which control the
  same things, and you'd like them to transition at "about" the same
  time?

  I don't think this API will allow you to do "at exactly the same
  time (modulo RC delay 8-)" even if the HW supports it...  That's
  probably OK.  But e.g. multiple syscalls and being context switched
  away may make it a long long time.

  Dunno if it's that important.

* similarly, if you've got multiple, it may be annoying to have to
  break a single request into N different writes.  (e.g. imagine a
  7-segment LCD driver done with GPIOs...  timing not critical, but,
  boy, having do split that character into N bits...  it's annoying.)

* Re: interrupts: dunno that it's sensible to try to expose them to
  userland (or to allow userland to configure GPIOs to raise
  interrupts).

  Disregarding the "how do you get the interrupt to the user program,"
  what do you do, mask them until the user program does ... something?

  don't think it needs to be done up front.


> Anyone have any (useful :-) input they could provide on this?  (Chris? :-)

mmm, gpios.  8-)

-- 
Chris Demetriou                                            Broadcom Corporation
Senior Staff Design Engineer                  Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.