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

[Linus Walleij]

On Fri, Mar 22, 2013 at 11:52 PM, Jon Hunter <jon-hunter at ti.com> wrote:
> On 03/22/2013 10:33 AM, Stephen Warren wrote:
>> On 03/22/2013 02:10 AM, Linus Walleij wrote:
>>> 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);
>>
>> That doesn't make any sense at all. Drivers don't want to care whether
>> the IRQ number they receive is a GPIO-that-can-act-like-an-IRQ or a pure
>> dedicated IRQ input.
>>
>> To fully support the model you proprose, a driver would have to:
>>
>> if (gpio_is_valid(pdata->gpio)) {
>>       gpio_request_one(pdata->gpio, GPIOF_IN, "foo irq");
>>       irq = gpio_to_irq(pdata->gpio);
>> } else
>>       irq = pdata->irq;
>> request_irq(...);
>>
>> which means complex code in each driver, plus requiring some indication
>> in platform data and/or device tree re: whether the IRQ is hosted by a
>> GPIO or not.

I suspect the above is just referring to the DT or similar usecases
(such as ACPI)?

We already have a number of platforms passing IRQ numbers
for something that is actually a GPIO pin but we don't really
know and debugfs doesn't say because they never
issue gpio_request() of the pin. And that's something I
don't like.

Because that is loosing control over the GPIO numberspace
not quite knowing which pin is used and which one isn't
and making these things prone to bugs.

What worries me is changing kernel semantics to fit device tree,
I think it is better to try to confine this to the drivers/gpio/gpiolib-of.c
file.

I'd like OF GPIO code to hog the pin using gpio_request(),
then figure out the IRQ number using gpio_to_irq() and pass
that out when picking an IRQ right out of a GPIO controllers
DT node. And I'd like it to be compulsory exercise to list
that one GPIO line as an input hog when used for just
some IRQ line.

This is what I would want to achieve by the GPIO hog concept.

> I tend to agree with Stephen here. When we had discussed this previously
> you had mentioned about adding a platform function to request the gpio
> [1], but I could see this adding a bunch more platform files when we are
> trying to get rid of all the board-xxx.c files for OMAP. So if you don't
> like the approach suggested by Stephen and implemented by Javier, then
> may be we need to means to request/reserve gpios in the dts as you had
> suggested before [1].
>
> So it seems to me that there are two options at the moment ...
>
> 1. Add a irq_chip request as suggested by Stephen.
> 2. Reserve/request gpios in the dts when registering a gpio chip.

This seems like you need to bring in Grant for a second opinion I'm
getting confused by this now... Paging Alexandre who's doing
the GPIO descriptor refactoring as well.

> [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/92327

Is there anything wrong with the GPIO hog concept as presented in the
mentioned reply?

+                input-hog-gpios = <4>, <5>;

Would result in these GPIOs being requested, so we can keep
track of them in e.g.  drivers/gpio/gpiolib-of.c, then supply
IRQs from these hogged inputs on demand from drivers.

But with the requirement that they be hogged, so we can keep
track of them, and they show up with some sensible
name in <debugfs>/gpio.

Yours,
Linus Walleij