Messages in this thread | | | Date | Wed, 8 Nov 2006 23:47:36 +0100 | From | "Haavard Skinnemoen" <> | Subject | Re: [-mm patch 1/4] GPIO framework for AVR32 |
| |
On 11/8/06, David Brownell <david-b@pacbell.net> wrote: > > The request/free calls aren't really arch-specific, are they? > > Remember that where one platform may use numbers 32-159 for GPIOs, another > might use 0-71 ... GPIO numbering has an arch-specific core, but whether > a given board adds more GPIOs from an FPGA or other non-SOC chip is even > more variable than "arch-specific".
Sorry, I'm having trouble expressing myself clearly today ;-)
I didn't mean to suggest that the interpretation of the numbers or the gpio_request() implementation should be arch-independent. I was merely suggesting that the _concept_ of requesting GPIO pins before using them, keeping track of which pins have been allocated before, isn't something inherently arch-specific.
I'm all for leaving it up to each arch or possibly each sub-arch how to implement the request/free functions. They can even be implemented as no-op stubs that always succeed for all I care. But I don't think any arch or platform will really have much trouble with implementing some kind of "please reserve this gpio pin represented as an unsigned int for me" call.
> > I implement the actual allocation mechanism using atomic bitops. > > That's a fair way to implement it, sure; but if you look at e.g. how > OMAP does it, the bitmap is inside a per-controller structure. When > one chip has two different _types_ of GPIO controller, and multiple > instances of one (plus restrictions applying to specific instances), > the notion of an arch-neutral implementation there seems unworkable.
Agreed. The avr32 implementation also uses a per-controller bitmap and supports any number of instances (up to a compile-time limit since it is initialized too early to be able to allocate any memory.) It doesn't support different type of controllers though; that would require some kind of demuxing and should probably be avoided on platforms that don't need it.
Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |