Re: [patch 2.6.20-rc1 5/6] SA1100 GPIO wrappers

[David Brownell <david-b@pacbell.net>]

On Saturday 23 December 2006 3:37 am, Russell King wrote:

> Why do we need to convert between IRQ and PGIO numbers?

(I take it that's the only real issue you had with this patch, other
than maybe excessive #includes?)


I suppose we could do with a one way mapping:  GPIO-to-IRQ, then
require drivers map the other way themselves when they need to.
As they must do with DMA addresses.

Having that GPIO-to-IRQ mapping is quite routine; and necessary.

On the other hand, since it's a (small) one-to-one mapping, I don't
see any real issue with defining how to access it in both directions.
I can tell one direction (IRQ-to-GPIO) bothers you ... but not why.


> When the interrupt system is asked to claim a IRQ corresponding to a
> GPIO, it should deal with all the stuff necessary to ensure that the
> GPIO is in the required state.

IRQ framework can't do "all" the needed stuff on platforms (like OMAP1)
where knowing the GPIO (presumably from a private IRQ-to-GPIO mapping??)
doesn't tell you what pin to set up, or how.  Such setup needs to be in
place *before* request_irq() is called.  The genirq irqchip.startup()
call could potentially sanity check whether a GPIO is configured as an
input, but couldn't handle pin muxing or pullup/pulldown config; and
I'd argue it shouldn't try to change anyt of that, since it's an API
for managing IRQs not for pin configuration.


> 	are we expecting to add GPIO
> support to all Linux drivers which could possibly be used on ARM, just
> because their interrupt pin might possibly be connected to a GPIO?

I'd expect board-specific setup code to pass gpio_to_irq(gpio_num) to
drivers when the _only_ thing that matters is its IRQ-ness.  And to
have previousy set up the relevant pin as a GPIO input ... so that most
drivers would just see an IRQ, much like any other irq.

That's what most of them do now, I didn't propose changing any part of
that except defining a standard way to write the GPIO-to-IRQ mapping.


The overall goal is basically to let drivers which know they've got a
GPIO have a standard way to use it ... in the previous situation, the
lack of such a portable API means those drivers must be (needlessly)
platform-specific.


> This is NOT 
> something that drivers should even care about - it's something that the
> interrupt subsystem should know when being asked to claim an GPIO-based
> IRQ.

It's admittedly uncommon that drivers care about IRQ-to-GPIO, but it's
not a "never" thing.  Drivers often need to care more about the exact
state of the signal than "IRQ triggered a while back"; and that means
some kind of IRQ-to-GPIO mapping.

Examples: systems that only have "both edges" triggering, where the
hardware signal is level triggered; or the supported triggering modes
are otherwise not a good match for an external chip.  State when the
driver starts up may need to check signal level directly, when the
IRQ must use edge triggering.  Also, disabling an IRQ at the source
(vs. unsharably masking it in the local IRQ controller) can sometimes
take much of a millisecond because of I2C or similar delays, making
it likely that signal state changed since the irq triggered.  Oh, and
the reverse mapping could also be useful for diagnostics.


> Get real - if you're dealing with IRQs use _only_ IRQ numbers.  Don't
> even think that drivers should be able to convert between IRQ and GPIO
> numbers.

I was being real, and I gave some examples above where drivers need to
be able to detect the actual signal level.

On the other hand it'd also be practical to force drivers to do that
mapping from IRQ (they probably only handle a few!) to GPIO, when they
need to do that, if they're given a GPIO number directly.  Then they'd
just use the GPIO-to-IRQ mapping to request the IRQ (already a common
idiom) and directly access the gpio state.

- Dave