[PATCH 3/5] gpio/omap: Add DT support to GPIO driver

[Linus Walleij]

On Fri, Mar 15, 2013 at 12:21 PM, Javier Martinez Canillas
<martinez.javier at gmail.com> wrote:

> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 159f5c5..f5feb43 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -807,6 +807,13 @@ static void gpio_unmask_irq(struct irq_data *d)
>         spin_unlock_irqrestore(&bank->lock, flags);
>  }
>
> +static int gpio_irq_request(struct irq_data *d)
> +{
> +       struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> +       return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
> +}
> +
>  static struct irq_chip gpio_irq_chip = {
>         .name           = "GPIO",
>         .irq_shutdown   = gpio_irq_shutdown,
> @@ -815,6 +822,7 @@ static struct irq_chip gpio_irq_chip = {
>         .irq_unmask     = gpio_unmask_irq,
>         .irq_set_type   = gpio_irq_type,
>         .irq_set_wake   = gpio_wake_enable,
> +       .irq_request    = gpio_irq_request,
>  };

This is just turning everything on it's head. The normal order of things
is this sequence for GPIO 14 something like:

gpio_request(14);
int irq = gpio_to_irq(14);
request_any_context_irq(irq);

I understand that the approach take make things easier for device tree
but it screws up the semantics of the entire kernel (the lockdep etc
warnings are just a symptom), we are locked to the above semantic
sequence: you know the GPIO, *then* you get the IRQ, not the
other way around.

irq_to_gpio has been deemed a legacy thing that we want to get
rid of. The reason being that it is ambiguous on most every GPIO
expander out there. It is not supported by GPIOLIB. This is the
reason to why the implementation in the GPIOLIB in
<linux/gpio.h> looks like this:

static inline int irq_to_gpio(unsigned int irq)
{
        return -EINVAL;
}

The only chance to have the function is in a non-gpiolib platform
that override it.

The irq_to_gpio() in gpio-omap.c overrides this and should
cause compile warnings, does it not?

There is a reason every other driver in drivers/gpio has renamed
this function to things like pxa_irq_to_gpio, msm_irq_to_gpio:
we just don't support it generically.

I know I'm not very helpful, I can just say this is not going to work. :-/

It seems you need a way to get the GPIO corresponding to a certain
IRQ from the device tree, not from the kernel as is done here, then
follow the mentioned sequence.

Yours,
Linus Walleij