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

[Linus Walleij]

On Fri, Mar 29, 2013 at 6:01 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 03/27/2013 02:55 PM, Linus Walleij wrote:
>> On Wed, Mar 27, 2013 at 5:09 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>> This is the case for some SMSC911x clients like the snowball
>> routing it to a GPIO, whereas I think the RealView and Integrator/CP
>> has a dedicated IRQ line for it on the FPGA so it's a good example.
>>
>> In such cases the right thing to do is for the platform
>> code populating the platform data with the int irq field, or device tree
>> core, or whatever piece of code that knows about
>> the actual GPIO shall start from the GPIO, request it and
>> then convert it to an IRQ.
>
> So board code could easily do that; plenty of opportunity to put
> whatever custom code is needed right there.
>
> For DT core code to do that, we'd need some alternative way of
> specifying interrupts. That would change the DT bindings for interrupts.
> I don't think we can do that...

Sorry, I'm probably not knowledgeable about DT to understand this.
The information for what GPIO corresponds to what IRQ is
present in the device tree, is it not?

If the information is there, whether to convert from IRQ to GPIO
or from GPIO to IRQ is a technicality and any order should be
feasible in some way?

I just can't get the necessity to do it one way preferred over the
other through my head, sorry...

>> If it seems like identical boilerplate in every machine we can
>> simply centralize it to gpiolib. Something like
>>
>> int gpio_add_single_irq_resource(struct platform_device *pdev, int
>> gpio, unsigned flags)
> ... [code to convert GPIO to IRQ and create IORESOURCE_IRQ from it]
>
>> int gpio_populate_irq_resource(struct platform_device *pdev, int gpio,
>>                               unsigned flags, struct resource *r)
> ... [code to create IORESOURCE_IRQ from the IRQ]
>
> ...
>> gpio_populate_irq_resource(&ethernet, 17,
>>      IORESOURCE_IRQ_HIGHEDGE, &ethernet_res[1]);
>> platform_device_register(&ethernet);
>>
>> That populates the device with the single GPIO IRQ from
>> the GPIO number in a smooth way.
>>
>> Of course it has to be done after the GPIO driver is up
>> and running so may require some other refactoring,
>> but it should work.
>
> That latter issue also somewhat scuppers this approach; then you have to
> somehow run a bunch of your board file code inter-mixed with various
> driver probe() calls. That will quickly get nasy.

No, just use a module_init() for the above code in the board
file and it will defer just like any other initcall.

> And it doesn't address how the DT core will know when to call
> gpio_add_single_irq_resource() vs. gpio_populate_irq_resource() without
> changing the DT binding for interrupts.

Is it not possible to do this in
drivers/gpio/gpiolib-of.c: of_gpiochip_add(), if the DT *know*
which GPIOs will be used as plain IRQs? That is the point with
the gpio hogs I talk about ...

GPIO hogs would hog input pins here and immediately
call gpio_to_irq() on them, and from that point on they can
only be used for input, and only for generating IRQs.

>>> And then, given that irq_to_gpio() isn't semantically possible, there's
>>> no way for the driver to be able to gpio_request() anything, since it
>>> doesn't, can't, and shouldn't know whether there is in fact any GPIO ID
>>> that it should request, let alone what that GPIO ID is.
>>
>> That's cool. The driver does not have to know the IRQ is backed by a
>> GPIO, but somewhere in the system something should know this.
>
> Something already does; the irqchip driver for the IRQ in question would
> always know whether it's programming a plain IRQ controller, or an IRQ
> controller that's part of a GPIO controller. In the GPIO case, the
> irqchip driver also has enought HW-specific information to perform
> whatever GPIO<->IRQ number conversion is needed.

So I'm opposed to doing these things both ways because
I think it's getting messy. We have already has irq_to_gpio()
cause problems in the past and this reminds me heavily
about that.

> Or, were you thinking of creating some kind of hogging system for
> gpiolib itself?

Yes.

Yours,
Linus Walleij