Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation

[David Brownell <david-b@pacbell.net>]

On Tuesday 21 November 2006 1:11 am, Haavard Skinnemoen wrote:

> > Or if you want to track the identifiers and provide a debugfs dump
> > of the active GPIOs and their status, use an array of strings (and
> > spinlock its updates) or nuls as "fat bits", instead of a bit array.  
> 
> Might be useful. Maybe we should add a "struct device" parameter to
> gpio_request() as well, to allow platforms to associate pins with the
> devices using them through sysfs? Or perhaps just to generate an
> appropriate name (otherwise, each driver would have to generate a
> unique string by themselves, for each device it controls.)

I'm not so keeen on putting sysfs everywhere; it's not free!
The notion of passing a device node makes some sense, except
that a lot of the places I'm used to seeing GPIO requests are
so early in the boot code that there _is_ no device node yet.
Let me think about that one a bit...



> I think I understand now. I have to use separate bitmasks for GPIO and
> port mux setup.
> 
> If gpio_request() could do port mux configuration, one bitmask would be
> enough to trap all errors. But after reading the rest of this thread,
> I think separating the gpio and portmux APIs is a good idea, so I'm not
> going to try to do this. Although I might set a bit in both masks when
> configuring a pin for peripheral I/O, just to indicate that it isn't
> usable for gpio at all.

On your hardware, you could just read the hardware when setting
the gpio direction ... don't need an extra mask to catch that
class of error.


> > > Of course, if other arches want gpio_request()/gpio_free(), I'm all
> > > for keeping them.
> > 
> > I thought you were someone who _wanted_ this mechanism?
> > Or were you instead thinking of a pin mux mechanism?
> 
> Yes and yes ;)
> 
> Which is of course the source of all this confusion. I just had to
> realize that the final definition of gpio_request was I little bit
> different than I originally expected. This means that gpio_request() is
> no longer _essential_ on avr32 (which corresponds nicely with its
> classification as "optional" in your api proposal) but very nice to
> have.

Right; I think I've had the OMAP analogue of gpio_request() turn
up errors only once (that code base was once a lot dirtier), but
some newish debug dump code worked a lot better with that.


> > Aren't you going to want to add AVR-specific extensions so that
> > drivers (or more typically, board init code) can manage pullups
> > and input de-glitching?
> 
> Yeah, I will definitely do that, but I thought that was supposed to be
> part of the portmux api?

Yes it is.  I suppose I shouldn't have assumed it would go into
that gpio.h header file, even though that's where it started out
on the at91 platform.  :)

- Dave