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

["Thiago Galesi" <thiagogalesi@gmail.com>]

Ok, some ideas:

> 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).

I guess that a kind of "name addressing" would be the way to go, we
need to get to it by "location" (I'm thinking PortA 20, PortB 5 rather
than pin number or some other arbitrary convention; we need a way to
not need to look up what 'Port X pin B' should be called.

> 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.

Seconded

> 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.

Agreed, but maybe 'not now'

Another thing that may be considered is the ability to get 'pointers'
for GPIOs. And, of course, protecting GPIOs from concurrent accesses

--
-
Thiago Galesi
-
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/