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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
