[lkml]   [2006]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
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.


> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-13 18:59    [W:0.293 / U:1.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site