Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.



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
Please read the FAQ at

[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]
  Powered by Linux