On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
<linus.walleij@xxxxxxxxxx> wrote:
> On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
> <martinez.javier@xxxxxxxxx> wrote:
>
>> Is the following inlined patch [1] what you were thinking that would
>> be the right approach?
Hi Linus, thanks a lot for your feedback.
>
> This looks sort of OK, but I'm still struggling with the question of
> what we could do to help other implementations facing the same issue.
>
Yes, I don't know how we can make it easier to other implementations
(besides adding the irq_request hook to irq_chip) since the logic is
GPIO controller specific.
For example I took a look to drivers/gpio/gpio-tegra.c and if I
understood correctly, the implementation for this driver should be
something like this:
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 414ad91..a2d5c3d 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -346,6 +346,11 @@ static int tegra_gpio_wake_enable(struct irq_data
*d, unsigned int enable)
}
#endif
+static int tegra_gpio_irq_request(struct irq_data *d)
+{
+ tegra_gpio_request(NULL, d->hwirq);
+}
+
static struct irq_chip tegra_gpio_irq_chip = {
.name = "GPIO",
.irq_ack = tegra_gpio_irq_ack,
@@ -355,6 +360,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
#ifdef CONFIG_PM_SLEEP
.irq_set_wake = tegra_gpio_wake_enable,
#endif
+ .irq_request = tegra_gpio_irq_request,
};
static const struct dev_pm_ops tegra_gpio_pm_ops = {
This is definitely quite similar to the omap-gpio.c change but not the same.
> This is a pretty hard design pattern to properly replicate in every such
> driver is it not?
>
> Hmmmm
>
Is indeed a hard design pattern but I couldn't figure out a more
generic way to handle this.
Maybe we could use [1] for now to solve the issue that we have with
OMAP GPIO and later when the same issue is found on other GPIO
controllers and a similar change is made on these drivers we will see
some form of pattern that emerge allowing us to make a later refactor
to reduce the code duplication.
Or do you have a better idea on how to solve this?
> Yours,
> Linus Walleij
Best regards,
Javier
--
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
