On Monday 13 November 2006 9:38 am, Paul Mundt wrote:
Comments?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,
Pin numbers are NOT exposed ... GPIO numbers are. Drivers just get
a number and pass it around. They're cookies with the same kinds of
portability attributes as IRQ numbers and register addresses. (None of
which have particular portability problems when used properly.)
And all those existing ARM GPIO calls work just fine with numbers
for GPIOs. The numbers are platform-specific, sometimes with board
specific additions (like FPGA outputs) ... but they're just numbers.
(And FWIW, I'm more familiar with "balls" like AA12 or J15 being relevant,
than pins like 1 or 332. Of course one could assign numbers to balls,
but the mappings for a BGA-256 would be different from ones on a BGA-193
or a BGA-289. And yet the same logical GPIO -- accessed through the same
software registers -- might be available with all of those packages!
Sometimes on more than one pin. Such issues are associated with pin
mux/config, not GPIO numbering.)
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.
This API absolutely allows for multiple GPIO controllers ... all it does
is say "here are the numbers, handle them". The platform's implementation
of the API is allowed to map to the relevant controller.