From: Javier Martinez Canillas <martinez.javier@gmail.com> To: Grant Likely <grant.likely@secretlab.ca> Cc: Jon Hunter <jon-hunter@ti.com>, Stephen Warren <swarren@wwwdotorg.org>, Stephen Warren <swarren@nvidia.com>, Kevin Hilman <khilman@deeprootsystems.com>, "devicetree-discuss@lists.ozlabs.org" <devicetree-discuss@lists.ozlabs.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, Tarun Kanti DebBarma <tarun.kanti@ti.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver Date: Fri, 15 Mar 2013 12:21:56 +0100 [thread overview] Message-ID: <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com> (raw) In-Reply-To: <51391F41.5000303@ti.com> On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter <jon-hunter@ti.com> wrote: > > On 03/02/2013 02:05 PM, Grant Likely wrote: >> On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter <jon-hunter@ti.com> wrote: >>> >>> On 02/26/2013 04:44 PM, Stephen Warren wrote: >>>> On 02/26/2013 03:40 PM, Jon Hunter wrote: >>>>> On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote: >>>>> Are you requesting the gpio anywhere? If not then this is not going to >>>>> work as-is. This was discussed fairly recently [1] and the conclusion >>>>> was that the gpio needs to be requested before we can use as an interrupt. >>>> >>>> That seems wrong; the GPIO/IRQ driver should handle this internally. The >>>> Ethernet driver shouldn't know/care whether the interrupt it's given is >>>> some form of dedicated interrupt or a GPIO-based interrupt, and even if >>>> it somehow did, there's no irq_to_gpio() any more, so the driver can't >>>> tell which GPIO ID it should request, unless it's given yet another >>>> property to represent this. >>> >>> I agree that ideally this should be handled internally. Did you read the >>> discussion on the thread that I referenced [1]? If you have any thoughts >>> we are open to ideas :-) >> >> I'm on an airplane right now, but I agree 100% with Stephen. I'll try to >> remember to go read that thread and respond, but this falls firmly in >> the its-a-bug category for me. :-) > > Grant, did you have chance to review the thread [1]? > > I am trying to figure out if we should just take the original patch > proposed in the thread (although Linus had some objections) or look at > alternative solutions such as adding a irq_chip request as Stephen > suggested. > > Cheers > Jon > > [1] comments.gmane.org/gmane.linux.ports.arm.omap/92192 Hello Grant, I was wondering if you have any opinions on this issue. As Jon said, Stephen proposed [2] to add a request callback to irq_chip. I hacked a very simple and naive patch (just to validate the idea) and is working. The GPIO bank is requested before calling the gpio-omap .irq_set_type function handler (gpio_irq_type) when using a GPIO as an IRQ on a DT. So is not necessary to call it explicitly anymore. But the patch is obviously wrong (to say the least) since the kernel runtime locking validator complains that "possible circular locking dependency detected" I just wanted to know if I was on the right track or completely lost here. Thanks a lot and best regards, javier [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html 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, }; /*---------------------------------------------------------------------*/ diff --git a/include/linux/irq.h b/include/linux/irq.h index bc4e066..2aeaa24 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -303,6 +303,7 @@ struct irq_chip { void (*irq_shutdown)(struct irq_data *data); void (*irq_enable)(struct irq_data *data); void (*irq_disable)(struct irq_data *data); + int (*irq_request)(struct irq_data *data); void (*irq_ack)(struct irq_data *data); void (*irq_mask)(struct irq_data *data); diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index fa17855..07c20f7 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1093,6 +1093,13 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new) if (!shared) { init_waitqueue_head(&desc->wait_for_threads); + if (desc->irq_data.chip->irq_request) { + ret = desc->irq_data.chip->irq_request(&desc->irq_data); + + if (ret) + goto out_mask; + } + /* Setup the type (level, edge polarity) if configured: */ if (new->flags & IRQF_TRIGGER_MASK) { ret = __irq_set_trigger(desc, irq,
WARNING: multiple messages have this Message-ID (diff)
From: martinez.javier@gmail.com (Javier Martinez Canillas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver Date: Fri, 15 Mar 2013 12:21:56 +0100 [thread overview] Message-ID: <CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com> (raw) In-Reply-To: <51391F41.5000303@ti.com> On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter <jon-hunter@ti.com> wrote: > > On 03/02/2013 02:05 PM, Grant Likely wrote: >> On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter <jon-hunter@ti.com> wrote: >>> >>> On 02/26/2013 04:44 PM, Stephen Warren wrote: >>>> On 02/26/2013 03:40 PM, Jon Hunter wrote: >>>>> On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote: >>>>> Are you requesting the gpio anywhere? If not then this is not going to >>>>> work as-is. This was discussed fairly recently [1] and the conclusion >>>>> was that the gpio needs to be requested before we can use as an interrupt. >>>> >>>> That seems wrong; the GPIO/IRQ driver should handle this internally. The >>>> Ethernet driver shouldn't know/care whether the interrupt it's given is >>>> some form of dedicated interrupt or a GPIO-based interrupt, and even if >>>> it somehow did, there's no irq_to_gpio() any more, so the driver can't >>>> tell which GPIO ID it should request, unless it's given yet another >>>> property to represent this. >>> >>> I agree that ideally this should be handled internally. Did you read the >>> discussion on the thread that I referenced [1]? If you have any thoughts >>> we are open to ideas :-) >> >> I'm on an airplane right now, but I agree 100% with Stephen. I'll try to >> remember to go read that thread and respond, but this falls firmly in >> the its-a-bug category for me. :-) > > Grant, did you have chance to review the thread [1]? > > I am trying to figure out if we should just take the original patch > proposed in the thread (although Linus had some objections) or look at > alternative solutions such as adding a irq_chip request as Stephen > suggested. > > Cheers > Jon > > [1] comments.gmane.org/gmane.linux.ports.arm.omap/92192 Hello Grant, I was wondering if you have any opinions on this issue. As Jon said, Stephen proposed [2] to add a request callback to irq_chip. I hacked a very simple and naive patch (just to validate the idea) and is working. The GPIO bank is requested before calling the gpio-omap .irq_set_type function handler (gpio_irq_type) when using a GPIO as an IRQ on a DT. So is not necessary to call it explicitly anymore. But the patch is obviously wrong (to say the least) since the kernel runtime locking validator complains that "possible circular locking dependency detected" I just wanted to know if I was on the right track or completely lost here. Thanks a lot and best regards, javier [2]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg85592.html 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, }; /*---------------------------------------------------------------------*/ diff --git a/include/linux/irq.h b/include/linux/irq.h index bc4e066..2aeaa24 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -303,6 +303,7 @@ struct irq_chip { void (*irq_shutdown)(struct irq_data *data); void (*irq_enable)(struct irq_data *data); void (*irq_disable)(struct irq_data *data); + int (*irq_request)(struct irq_data *data); void (*irq_ack)(struct irq_data *data); void (*irq_mask)(struct irq_data *data); diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index fa17855..07c20f7 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -1093,6 +1093,13 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new) if (!shared) { init_waitqueue_head(&desc->wait_for_threads); + if (desc->irq_data.chip->irq_request) { + ret = desc->irq_data.chip->irq_request(&desc->irq_data); + + if (ret) + goto out_mask; + } + /* Setup the type (level, edge polarity) if configured: */ if (new->flags & IRQF_TRIGGER_MASK) { ret = __irq_set_trigger(desc, irq,
next prev parent reply other threads:[~2013-03-15 11:21 UTC|newest] Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-15 16:04 [PATCH 0/5] gpio/omap: Cleanup and adaptation to Device Tree Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson 2012-02-15 16:04 ` [PATCH 1/5] gpio/omap: Remove bank->id information and misc cleanup Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson 2012-02-16 5:53 ` DebBarma, Tarun Kanti 2012-02-16 5:53 ` DebBarma, Tarun Kanti 2012-02-16 9:33 ` Cousson, Benoit 2012-02-16 9:33 ` Cousson, Benoit 2012-02-15 16:04 ` [PATCH 2/5] gpio/omap: Use devm_ API and add request_mem_region Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson 2012-02-16 5:41 ` DebBarma, Tarun Kanti 2012-02-16 5:41 ` DebBarma, Tarun Kanti 2012-02-16 6:35 ` Grant Likely 2012-02-16 6:35 ` Grant Likely 2012-02-16 7:11 ` DebBarma, Tarun Kanti 2012-02-16 7:11 ` DebBarma, Tarun Kanti 2012-02-16 6:37 ` Shubhrajyoti 2012-02-16 6:37 ` Shubhrajyoti 2012-02-16 8:56 ` Cousson, Benoit 2012-02-16 8:56 ` Cousson, Benoit 2012-02-15 16:04 ` [PATCH 3/5] gpio/omap: Add DT support to GPIO driver Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson 2012-02-22 14:23 ` Rob Herring 2012-02-22 14:23 ` Rob Herring 2012-02-22 14:31 ` Cousson, Benoit 2012-02-22 14:31 ` Cousson, Benoit 2012-02-22 17:23 ` Rob Herring 2012-02-22 17:23 ` Rob Herring 2012-02-22 18:29 ` Stephen Warren 2012-02-22 18:29 ` Stephen Warren 2012-02-24 15:30 ` Cousson, Benoit 2012-02-24 15:30 ` Cousson, Benoit 2013-02-26 10:01 ` Javier Martinez Canillas 2013-02-26 10:01 ` Javier Martinez Canillas 2013-02-26 16:33 ` Stephen Warren 2013-02-26 16:33 ` Stephen Warren 2013-02-26 22:40 ` Jon Hunter 2013-02-26 22:40 ` Jon Hunter 2013-02-26 22:44 ` Stephen Warren 2013-02-26 22:44 ` Stephen Warren 2013-02-26 23:01 ` Jon Hunter 2013-02-26 23:01 ` Jon Hunter 2013-02-26 23:06 ` Stephen Warren 2013-02-26 23:06 ` Stephen Warren 2013-02-26 23:45 ` Jon Hunter 2013-02-26 23:45 ` Jon Hunter 2013-02-27 0:13 ` Stephen Warren 2013-02-27 0:13 ` Stephen Warren 2013-02-27 1:07 ` Jon Hunter 2013-02-27 1:07 ` Jon Hunter 2013-02-27 3:57 ` Javier Martinez Canillas 2013-02-27 3:57 ` Javier Martinez Canillas 2013-02-27 17:50 ` Stephen Warren 2013-02-27 17:50 ` Stephen Warren 2013-02-27 20:05 ` Javier Martinez Canillas 2013-02-27 20:05 ` Javier Martinez Canillas 2013-02-27 23:16 ` Jon Hunter 2013-02-27 23:16 ` Jon Hunter 2013-02-28 12:17 ` Javier Martinez Canillas 2013-02-28 12:17 ` Javier Martinez Canillas 2013-02-28 20:49 ` Jon Hunter 2013-02-28 20:49 ` Jon Hunter [not found] ` <512D3EC2.6050408-l0cyMroinI0@public.gmane.org> 2013-03-02 20:05 ` Grant Likely 2013-03-02 20:05 ` Grant Likely 2013-03-07 23:14 ` Jon Hunter 2013-03-07 23:14 ` Jon Hunter 2013-03-15 11:21 ` Javier Martinez Canillas [this message] 2013-03-15 11:21 ` Javier Martinez Canillas 2013-03-22 8:10 ` Linus Walleij 2013-03-22 8:10 ` Linus Walleij 2013-03-22 15:33 ` Stephen Warren 2013-03-22 15:33 ` Stephen Warren 2013-03-22 22:52 ` Jon Hunter 2013-03-22 22:52 ` Jon Hunter 2013-03-27 13:52 ` Linus Walleij 2013-03-27 13:52 ` Linus Walleij 2013-03-27 16:09 ` Stephen Warren 2013-03-27 16:09 ` Stephen Warren 2013-03-27 20:55 ` Linus Walleij 2013-03-27 20:55 ` Linus Walleij 2013-03-29 17:01 ` Stephen Warren 2013-03-29 17:01 ` Stephen Warren 2013-04-10 18:12 ` Linus Walleij 2013-04-10 18:12 ` Linus Walleij 2013-04-10 20:29 ` Stephen Warren 2013-04-10 20:29 ` Stephen Warren 2013-04-10 21:28 ` Linus Walleij 2013-04-10 21:28 ` Linus Walleij 2013-04-11 20:30 ` Stephen Warren 2013-04-11 20:30 ` Stephen Warren 2013-04-11 22:16 ` Linus Walleij 2013-04-11 22:16 ` Linus Walleij 2013-04-11 22:47 ` Stephen Warren 2013-04-11 22:47 ` Stephen Warren 2013-04-14 1:35 ` Javier Martinez Canillas 2013-04-14 1:35 ` Javier Martinez Canillas 2013-04-14 20:53 ` Linus Walleij 2013-04-14 20:53 ` Linus Walleij 2013-04-15 11:25 ` Javier Martinez Canillas 2013-04-15 11:25 ` Javier Martinez Canillas 2013-04-15 16:58 ` Stephen Warren 2013-04-15 16:58 ` Stephen Warren [not found] ` <516C73C6.5050409@ti.co m> 2013-04-15 21:40 ` Jon Hunter 2013-04-15 21:40 ` Jon Hunter 2013-04-15 21:44 ` Jon Hunter 2013-04-15 21:44 ` Jon Hunter 2013-04-15 22:16 ` Stephen Warren 2013-04-15 22:16 ` Stephen Warren 2013-04-15 23:04 ` Jon Hunter 2013-04-15 23:04 ` Jon Hunter 2013-04-16 18:40 ` Stephen Warren 2013-04-16 18:40 ` Stephen Warren 2013-04-16 19:27 ` Jon Hunter 2013-04-16 19:27 ` Jon Hunter 2013-04-16 21:57 ` Jon Hunter 2013-04-16 21:57 ` Jon Hunter 2013-04-16 22:11 ` Stephen Warren 2013-04-16 22:11 ` Stephen Warren 2013-04-16 23:14 ` Jon Hunter 2013-04-16 23:14 ` Jon Hunter 2013-04-17 0:41 ` Javier Martinez Canillas 2013-04-17 0:41 ` Javier Martinez Canillas 2013-04-17 2:00 ` Jon Hunter 2013-04-17 2:00 ` Jon Hunter 2013-04-17 7:55 ` Javier Martinez Canillas 2013-04-17 7:55 ` Javier Martinez Canillas [not found] ` <CAAwP0s2M2pnSydyDvh_rejFO=w8bCo4WE5PkxrYuk0HQDixc-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-04-17 13:25 ` Jon Hunter 2013-04-17 13:25 ` Jon Hunter 2013-04-17 13:42 ` Javier Martinez Canillas 2013-04-17 13:42 ` Javier Martinez Canillas [not found] ` <CAAwP0s2DsJAWuXWvPAkzCT0T0AG_OvMEw2sADW6LqSi1Ofd_Zw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-04-17 13:52 ` Jon Hunter 2013-04-17 13:52 ` Jon Hunter 2013-04-17 14:21 ` Javier Martinez Canillas 2013-04-17 14:21 ` Javier Martinez Canillas 2013-04-17 16:18 ` Javier Martinez Canillas 2013-04-17 16:18 ` Javier Martinez Canillas 2013-04-26 7:31 ` Linus Walleij 2013-04-26 7:31 ` Linus Walleij 2013-04-26 21:31 ` Jon Hunter 2013-04-26 21:31 ` Jon Hunter 2013-06-11 21:25 ` Grant Likely 2013-06-11 21:25 ` Grant Likely 2013-06-12 9:43 ` Linus Walleij 2013-06-12 9:43 ` Linus Walleij 2013-04-17 15:41 ` Stephen Warren 2013-04-17 15:41 ` Stephen Warren 2013-04-26 7:27 ` Linus Walleij 2013-04-26 7:27 ` Linus Walleij 2013-04-26 21:25 ` Jon Hunter 2013-04-26 21:25 ` Jon Hunter [not found] ` <517AF0C1.60009-l0cyMroinI0@public.gmane.org> 2013-05-03 14:35 ` Linus Walleij 2013-05-03 14:35 ` Linus Walleij 2013-04-26 7:11 ` Linus Walleij 2013-04-26 7:11 ` Linus Walleij 2013-04-26 6:59 ` Linus Walleij 2013-04-26 6:59 ` Linus Walleij 2013-04-15 16:53 ` Stephen Warren 2013-04-15 16:53 ` Stephen Warren 2013-04-15 20:00 ` Jon Hunter 2013-04-15 20:00 ` Jon Hunter 2013-04-11 22:49 ` Javier Martinez Canillas 2013-04-11 22:49 ` Javier Martinez Canillas 2013-04-11 22:51 ` Stephen Warren 2013-04-11 22:51 ` Stephen Warren 2013-04-10 21:44 ` Arnd Bergmann 2013-04-10 21:44 ` Arnd Bergmann 2013-02-27 3:33 ` Javier Martinez Canillas 2013-02-27 3:33 ` Javier Martinez Canillas 2013-02-27 17:47 ` Stephen Warren 2013-02-27 17:47 ` Stephen Warren 2013-02-27 20:00 ` Javier Martinez Canillas 2013-02-27 20:00 ` Javier Martinez Canillas 2013-02-26 23:08 ` Jon Hunter 2013-02-26 23:08 ` Jon Hunter 2013-02-27 3:47 ` Javier Martinez Canillas 2013-02-27 3:47 ` Javier Martinez Canillas 2013-02-27 20:13 ` Jon Hunter 2013-02-27 20:13 ` Jon Hunter 2013-02-27 23:41 ` Linus Walleij 2013-02-27 23:41 ` Linus Walleij 2013-02-28 13:04 ` Benoit Cousson 2013-02-28 13:04 ` Benoit Cousson 2013-03-01 0:09 ` Linus Walleij 2013-03-01 0:09 ` Linus Walleij 2013-03-01 0:42 ` Jon Hunter 2013-03-01 0:42 ` Jon Hunter 2012-02-15 16:04 ` [PATCH 4/5] arm/dts: OMAP4: Add gpio nodes Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson 2012-02-15 16:04 ` [PATCH 5/5] arm/dts: OMAP3: " Benoit Cousson 2012-02-15 16:04 ` Benoit Cousson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAAwP0s1CFRO-rf==p5sYs1n0gigMif7wuT8Yv0N_iLUDMrtcOg@mail.gmail.com' \ --to=martinez.javier@gmail.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=grant.likely@secretlab.ca \ --cc=jon-hunter@ti.com \ --cc=khilman@deeprootsystems.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=swarren@nvidia.com \ --cc=swarren@wwwdotorg.org \ --cc=tarun.kanti@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.