David Brownell wrote:
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.)
Honestly, I'm forced to go to this mentality more every day as well.
The AT91RM9200 is available in at least two packages, not all of which
have the same GPIO mapping (or even available lines!). And don't get me
started on PPC...
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.
I think what Paul is saying here is that because your reference
implementation was "arch-omap" instead of "board-<something>", if I add
a PLD with some MMIO GPIO lines then I have to hack global OMAP code.
Maybe we should codify an approach for that now, i.e. add to the
reference implementation some code that hands off out-of-range GPIO
lines to a function in the machine descriptor:
+static inline int gpio_direction_input(unsigned gpio)
+ { if (gpio < OMAP_MAX_ARCH_GPIO) return __gpio_set_direction(gpio, 1);
+ else if(mdesc->platform_gpio_set_direction) platform_gpio_set_direction(gpio, 1); }
... conveniently neglecting the way you find mdesc. :)
I do have a question now. Is there any reason to consider shared GPIO
lines? If so, then the request_gpio() would need a flag GPIO_SHARED or
something.
b.g.
--
Bill Gatliff
[email protected]
-
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]
