Re: [-mm patch 1/4] GPIO framework for AVR32

["Haavard Skinnemoen" <hskinnemoen@gmail.com>]

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