Paul Mundt wrote:
On Mon, Nov 13, 2006 at 12:19:11PM -0600, Bill Gatliff wrote:
True, but right now if the "multiple GPIO controllers" are on something
like i2c/spi, they have the synch/asynch issues that Jamey mentioned and
so are by definition out of scope for this proposal. If the GPIO lines
are in an MMIO controller (PLD/FPGA, perhaps), then there's no reason
that the board implementer couldn't address that in their implementation
of the proposed functions.
They're something that has to be accounted for in any sort of API, or we
just end up throwing it all out and starting over again. I was thinking
more of the SuperIO or mfd device scope, where this _is_ a requirement.
Right. I don't know anything about SuperIO/SH, but the mfd stuff I've
worked with to date (UCB1400, SM501) all provide for the various
functions by mapping them into existing APIs like i2c, ALSA, etc. which
aren't disturbed by Dave's proposal. They still have their limitations,
i.e. you wouldn't want to put an IDE controller out on one of the GPIO
lines of a UCB1400, a problem that Dave isn't trying to address.
... except that I bet David is thinking that the implementations will be
in arch/arm/irq-at91rm9200.c or something, and not in
asm/arm/board-xyz.c, so it's the arch implementer's responsibility and
not the platform author's. Yea, I see your point now.
The problem with this is that it gets in to something that's getting
close to static pin state configuration. Setting up the mux from platform
code is brain-damage, since it's ultimately up to the system and driver
inserted at the time to grab and configure the pin as necessary, the
board or CPU code is not going to have any notion of the "preferred" pin
state, especially in the heavily muxed case.
The platform _is_ the system, as far as the driver is concerned. I
think they're indistinguishable.
What the driver needs is an enumeration that it can hand to the GPIO
layer that says, "set this high" or "set this low", or "what is the
state on this line?". The platform_device structure is a great place to
pass it the enumerations that, deep in the bowels of the platform/system
code, map into actual GPIO lines. I don't think that's close to static
pin assignment any more than using the platform_device structure to pass
IRQ line enumerations is now. Think: today, most drivers don't know or
care if an IRQ line is edge-triggered or level-triggered. That code is
in the domain of the IRQ subsystem. What David is proposing is the same
sort of thing for GPIO.
This is all too late for 2.6.19 regardless. We've gone this long without
a generic API, I see no reason to merge a temporary hack now if it's not
going to be satisfactory for people and require us to throw it all out
and start over again anyways.
I don't see what David is proposing as being a temporary hack. Rather,
it's a starting point. We can add another layer on after the sync/async
issues are sorted out--- which I think is a challenging problem that
will take a while. I'd rather have some uniformity today that we can
use across ARM, and ultimately other arches as well.
I have a real need for supporting multiple controllers and handling
muxing dynamically from various drivers on various architectures, and
anything that exposes the pin # higher than the controller mapping to
function level is never going to work. Drivers have _zero_ interest in
pin #, only in the desired function.
Agreed.
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]
