On 03/27/2013 07:52 AM, Linus Walleij wrote:
> On Fri, Mar 22, 2013 at 11:52 PM, Jon Hunter <jon-hunter@xxxxxx> 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)?
...
> 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.
No, this has absolutely noting to do with device tree; the example I
gave above is purely based on platform data.
It's simply that if a device emits an IRQ, there's no reason to assume
that the IRQ is in fact a GPIO. It might be a dedicated IRQ input pin
and not something that gpiolib (or any other GPIO API) knows about.
One possibility:
(Device IRQ output wired into GPIO input on SoC which then generates an
interrupt)
+----------------------------+
| SoC | +--------+
| IRQ 5 +------+ GPIO 10 | DEV_IRQ | Device |
| GIC <---- | GPIO | <-------|---------|-IRQ |
| +------+ | +--------+
+----------------------------+
Another possibility:
(Device IRQ output wired directly into dedicated IRQ input pin, and that
pin has no GPIO capabilities)
+----------------------------+
| SoC | +--------+
| IRQ 5 | DEV_IRQ | Device |
| GIC <----------------------|---------|-IRQ |
| | +--------+
+----------------------------+
As such, the driver /must/ receive an "int irq" in platform data. If it
received an "int gpio", then there would be no way for the driver to
support boards that routed that interrupt signal to a dedicated IRQ pin
on the SoC, rather than to a GPIO pin that just happened to have
interrupt generation capabilities.
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.
And finally, even if we ignore dedicated IRQ input pins, and assume that
every IRQ input is really a GPIO, why should the driver be forced to
call both request_irq() and gpio_request(); that's something that should
really be dealt with inside the IRQ subsystem or relevant IRQ driver.
Otherwise, every other driver that uses IRQs has to be burdened with the
code to do that.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
