At Tue, 13 Aug 2002 15:32:51 +0000 (UTC), "Jason R Thorpe" wrote:
> Ok, first of all, do you see value in being able to set multiple pins
> in a single operation?

Some but:

> That's the point of having the "pins" passed
> in as an array.  I think if this *IS* allowed, then it needs to be
> qualified with "if you set multiple pins in one operation, the pins
> must all belong to the same underlying device" so that the operation
> can be atomic.

that seems kind-of a pain.  I think i'd rather not have the
functionality, if it'll require a bunch of checking in the kernel and
special-case implementation.

"don't make your clock transition at the same time as your data" and
you're OK.  8-)


> ...but I want to expose "toggle" to userland for scripts, and I wanted
> to have some sense of consistency.

Well, personally, if you're going to go there, i wouldn't mind seeing
'or, xor' exposed as an operation.

(letting you set, clear, or invert.)


>  > pulse?  "how wide?"  These things, and more, are important to people
>  > who fiddle with GPIOs!  8-)
> 
> A pulse could be open-coded, right?  Although, as Dan points out, this
> can often be quite sensitive to timing...

and you're not going to get that in userland.  8-)


> Ok, so, how about:
> 
> 	int gpio_pulse(struct gpio_pin *pins, int npins, u_int usec);
> 
> used like:
> 
> 	reset_pin.val = 0;
> 	gpio_pulse(&reset_pin, 1, 25);
> 
> ...which would do:
> 
> 	* Set pin to val (0).
> 	* Wait 25 microseconds.
> 	* Set pin to !val (1).
> 	* Return.

I suppose.


>  > > 	  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.)
> 
> Can you give me an idea of what the interface to this should look like?

err, well, it's really a "pick one of 2 settings" in the case I know
about.  I dunno about others.

i don't really know what a good generic interface would be.


>  > (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-)
> 
> No.  This would be the kind of scenario where you have a "generic bus
> IDE driver", which marks the pins it uses as "off limits" to the GPIO
> framework :-)

That's unfortunate: it means that you have to have two interfaces to
access GPIO pins.

(i.e., this common one, and one which does all of the setup, etc., for
things like drivers.)



cgd