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

[Bill Gatliff <bgat@billgatliff.com>]

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