Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

Bill Gatliff
2006-11-13T18:21:17Z

Paul:

Paul Mundt wrote:

>I'm not convinced that exposing the pin number to drivers is the way to
>go. The pin numbers themselves are rarely portable across "similar" CPUs
>with identical peripherals, while the pin function itself may be
>portable (or simply unecessary). Pin muxing also needs to be handled in a
>much more transparent and intelligent fashion, which is something else
>that is fairly easy to do when looking at a symbolic name for the pin
>function rather than the pin # itself.
>
>

I don't think he's exporting pin numbers per se. It's more like an
enumeration that comes in from the platform data that the driver passes
back to the GPIO (and, indirectly, the IRQ) API.

>Any API also needs to allow for multiple GPIO controllers, as it's rarely
>just the CPU that has these or needs to manipulate them.
>
>

True, but right now if the "multiple GPIO controllers" are on something
like i2c/spi, they have the synch/asynch issues that Jamey mentioned and
so are by definition out of scope for this proposal. If the GPIO lines
are in an MMIO controller (PLD/FPGA, perhaps), then there's no reason
that the board implementer couldn't address that in their implementation
of the proposed functions.

... except that I bet David is thinking that the implementations will be
in arch/arm/irq-at91rm9200.c or something, and not in
asm/arm/board-xyz.c, so it's the arch implementer's responsibility and
not the platform author's. Yea, I see your point now.

I say that we go with David's proposal for 2.6.19 anyway, and maybe by
2.6.20 we'll have a consensus on how to address that with some
behind-the-API magic. :) (functions added to the machine descriptor,
maybe?)

b.g. , who can't post to the lists at the moment because his ISP is
having a sudden fit of outbound email filter mania.

--
Bill Gatliff
bgat@billgatliff.com