On Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
> Why not have GPIO numbers refer to unique combinations of GPIO+pin?
That sounds unduly complicated compared to just using the GPIO numbers
which are used throughout the hardware and software docs. It'd also
be a big (and needless) disruption to code that's been working fine for
several years now ... and there'd need to be some scheme to recognize
that most GPIO numbers suddenly become invalid (since the space would
become large and sparsely populated, vs small and dense).
Maybe if it were being done over from scratch, that'd be workable.
But at this point I have a hard time seeing anyone want to change,
even if there were a better argument.
> If the GPIO line is tied to a piece of external hardware, that connection
> is surely through a specific pin. So it seems like you'd need GPIO+pin
> every time there was an option.
Pin muxing is set up once, early, and from then on it suffices to use
the GPIO number. The mux problems are orthogonal to GPIOs.
> It seems like the point
> here is to help a driver find and assert their GPIO _pin_ so that the
> driver can can talk to the attached external hardware.
Updating the GPIO controller is always (all architectures!) done in terms
of a number mapping to some controller and a bit number, not a pin. The
drivers never care about pins.
The only thing that cares about pins is board setup code -- briefly.
- Dave
-
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]
