From: Linus Walleij <linus.walleij@linaro.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Grant Likely <grant.likely@linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Alexander Holler <holler@ahsoftware.de>, Linux-OMAP <linux-omap@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Javier Martinez Canillas <javier.martinez@collabora.co.uk>, Enric Balletbo i Serra <eballetbo@gmail.com>, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>, Santosh Shilimkar <santosh.shilimkar@ti.com>, Kevin Hilman <khilman@linaro.org>, Balaji T K <balajitk@ti.com>, Tony Lindgren <tony@atomide.com>, Jon Hunter <jgchunter@gmail.com> Subject: Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs Date: Thu, 22 Aug 2013 00:02:39 +0200 [thread overview] Message-ID: <CACRpkdavR=fv+y1RCNfdgQypPuRbO6isOSwGsABDrYiGeMdyZw@mail.gmail.com> (raw) In-Reply-To: <344239800.bDEkDg48ZQ@avalon> On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: >> I don't see how sharing works here, or how another user, i.e. another one >> than the user wanting to recieve the IRQ, can validly request such a line? >> What would the usecase for that valid request be? > > When the GPIO is wired to a status signal (such as an MMC card detect signal) > the driver might want to read the state of the signal independently of the > interrupt handler. That is true. But for such a complex usecase I think it's reasonable that we only specify the GPIO in the device tree, and the driver utilizing the IRQ need to take that and perform gpio_to_irq() on it, and then it still works to use it both ways. >> Basically I believe these two things need to be exclusive in the DT world: >> >> A: request_irq(a resource passed from "interrupts"); >> -> core implicitly performs gpio_request() >> gpio_direction_input() >> >> B: gpio_request(a resource passed from "gpios"); >> gpio_direction_input() >> request_irq(gpio_to_irq()) >> >> Never both. And IIUC that was what happened in the OMAP case. > > Isn't the core issue that we can translate a GPIO number to an IRQ number, but > not the other way around ? If that could be done, we could request the GPIO > and configure it as an input when the IRQ is requested. That is true. It would be easier if all GPIO drivers has an irqchip and and irqdomain, then we could implement irq_to_gpio() properly in gpiolib and this would not be a problem. Alas, not all do. But I also think that the DT contains (as demonstrated by the patch) all information about what interrupts and GPIOs may conflict, so I also see this as something of a consistency check, but it could go in either way. Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs Date: Thu, 22 Aug 2013 00:02:39 +0200 [thread overview] Message-ID: <CACRpkdavR=fv+y1RCNfdgQypPuRbO6isOSwGsABDrYiGeMdyZw@mail.gmail.com> (raw) In-Reply-To: <344239800.bDEkDg48ZQ@avalon> On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: >> I don't see how sharing works here, or how another user, i.e. another one >> than the user wanting to recieve the IRQ, can validly request such a line? >> What would the usecase for that valid request be? > > When the GPIO is wired to a status signal (such as an MMC card detect signal) > the driver might want to read the state of the signal independently of the > interrupt handler. That is true. But for such a complex usecase I think it's reasonable that we only specify the GPIO in the device tree, and the driver utilizing the IRQ need to take that and perform gpio_to_irq() on it, and then it still works to use it both ways. >> Basically I believe these two things need to be exclusive in the DT world: >> >> A: request_irq(a resource passed from "interrupts"); >> -> core implicitly performs gpio_request() >> gpio_direction_input() >> >> B: gpio_request(a resource passed from "gpios"); >> gpio_direction_input() >> request_irq(gpio_to_irq()) >> >> Never both. And IIUC that was what happened in the OMAP case. > > Isn't the core issue that we can translate a GPIO number to an IRQ number, but > not the other way around ? If that could be done, we could request the GPIO > and configure it as an input when the IRQ is requested. That is true. It would be easier if all GPIO drivers has an irqchip and and irqdomain, then we could implement irq_to_gpio() properly in gpiolib and this would not be a problem. Alas, not all do. But I also think that the DT contains (as demonstrated by the patch) all information about what interrupts and GPIOs may conflict, so I also see this as something of a consistency check, but it could go in either way. Yours, Linus Walleij
next prev parent reply other threads:[~2013-08-21 22:02 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-29 12:36 [PATCH] RFC: interrupt consistency check for OF GPIO IRQs Linus Walleij 2013-07-30 4:30 ` Grant Likely 2013-07-30 4:30 ` Grant Likely 2013-07-30 4:30 ` Grant Likely 2013-07-30 23:44 ` Linus Walleij 2013-07-30 23:44 ` Linus Walleij 2013-07-30 23:44 ` Linus Walleij 2013-07-31 8:35 ` Javier Martinez Canillas 2013-07-31 8:35 ` Javier Martinez Canillas 2013-07-31 8:35 ` Javier Martinez Canillas 2013-08-02 9:57 ` Alexander Holler 2013-08-02 9:57 ` Alexander Holler 2013-08-02 9:57 ` Alexander Holler 2013-08-02 15:35 ` Alexander Holler 2013-08-02 15:35 ` Alexander Holler 2013-08-02 15:35 ` Alexander Holler 2013-08-03 7:23 ` Alexander Holler 2013-08-03 7:23 ` Alexander Holler 2013-08-03 7:23 ` Alexander Holler 2013-09-10 7:00 ` Joel Fernandes 2013-09-10 7:00 ` Joel Fernandes 2013-09-10 7:00 ` Joel Fernandes 2013-09-10 13:17 ` Javier Martinez Canillas 2013-09-10 13:17 ` Javier Martinez Canillas 2013-09-10 13:17 ` Javier Martinez Canillas 2013-09-10 15:00 ` Joel Fernandes 2013-09-10 15:00 ` Joel Fernandes 2013-09-10 15:00 ` Joel Fernandes 2013-09-10 15:48 ` Javier Martinez Canillas 2013-09-10 15:48 ` Javier Martinez Canillas 2013-09-10 15:48 ` Javier Martinez Canillas 2013-09-10 16:25 ` Joel Fernandes 2013-09-10 16:25 ` Joel Fernandes 2013-09-10 16:25 ` Joel Fernandes 2013-09-11 7:05 ` Alexander Holler 2013-09-11 7:05 ` Alexander Holler 2013-09-11 7:05 ` Alexander Holler 2013-09-11 7:16 ` Alexander Holler 2013-09-11 7:16 ` Alexander Holler 2013-09-11 7:16 ` Alexander Holler 2013-09-11 7:30 ` Alexander Holler 2013-09-11 7:30 ` Alexander Holler 2013-09-11 7:30 ` Alexander Holler 2013-09-11 7:36 ` Alexander Holler 2013-09-11 7:36 ` Alexander Holler 2013-09-11 7:36 ` Alexander Holler 2013-08-13 9:52 ` Lars Poeschel 2013-08-13 9:52 ` Lars Poeschel 2013-08-13 9:52 ` Lars Poeschel 2013-08-19 22:04 ` Laurent Pinchart 2013-08-19 22:04 ` Laurent Pinchart 2013-08-19 22:04 ` Laurent Pinchart 2013-08-21 22:02 ` Linus Walleij [this message] 2013-08-21 22:02 ` Linus Walleij 2013-08-21 22:02 ` Linus Walleij 2013-09-06 15:32 ` Laurent Pinchart 2013-09-06 15:32 ` Laurent Pinchart 2013-09-06 15:32 ` Laurent Pinchart 2013-09-11 15:30 ` Alexander Holler 2013-09-11 15:30 ` Alexander Holler 2013-09-11 15:30 ` Alexander Holler 2013-09-11 16:14 ` Javier Martinez Canillas 2013-09-11 16:14 ` Javier Martinez Canillas 2013-09-11 16:14 ` Javier Martinez Canillas 2013-09-11 17:42 ` Alexander Holler 2013-09-11 17:42 ` Alexander Holler 2013-09-11 17:42 ` Alexander Holler 2013-09-12 8:55 ` Alexander Holler 2013-09-12 8:55 ` Alexander Holler 2013-09-12 8:55 ` Alexander Holler 2013-09-12 10:11 ` Javier Martinez Canillas 2013-09-12 10:11 ` Javier Martinez Canillas 2013-09-12 10:11 ` Javier Martinez Canillas 2013-09-12 10:28 ` Alexander Holler 2013-09-12 10:28 ` Alexander Holler 2013-09-12 10:28 ` Alexander Holler 2013-09-12 11:09 ` Alexander Holler 2013-09-12 11:09 ` Alexander Holler 2013-09-12 11:09 ` Alexander Holler 2013-09-12 11:26 ` Alexander Holler 2013-09-12 11:26 ` Alexander Holler 2013-09-12 11:26 ` Alexander Holler 2013-09-12 11:37 ` Alexander Holler 2013-09-12 11:37 ` Alexander Holler 2013-09-12 11:37 ` Alexander Holler 2013-09-12 15:19 ` Stephen Warren 2013-09-12 15:19 ` Stephen Warren 2013-09-12 15:19 ` Stephen Warren 2013-09-12 15:57 ` Alexander Holler 2013-09-12 15:57 ` Alexander Holler 2013-09-12 15:57 ` Alexander Holler 2013-09-18 0:36 ` Grant Likely 2013-09-18 0:36 ` Grant Likely 2013-09-18 0:36 ` Grant Likely 2013-10-20 12:41 ` Laurent Pinchart 2013-10-20 12:41 ` Laurent Pinchart 2013-10-20 12:41 ` Laurent Pinchart 2013-10-20 15:51 ` Tony Lindgren 2013-10-20 15:51 ` Tony Lindgren 2013-10-20 15:51 ` Tony Lindgren 2013-10-20 21:35 ` Stephen Warren 2013-10-20 21:35 ` Stephen Warren 2013-10-20 21:35 ` Stephen Warren 2013-10-21 23:26 ` Laurent Pinchart 2013-10-21 23:26 ` Laurent Pinchart 2013-10-21 23:26 ` Laurent Pinchart
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='CACRpkdavR=fv+y1RCNfdgQypPuRbO6isOSwGsABDrYiGeMdyZw@mail.gmail.com' \ --to=linus.walleij@linaro.org \ --cc=balajitk@ti.com \ --cc=devicetree@vger.kernel.org \ --cc=eballetbo@gmail.com \ --cc=grant.likely@linaro.org \ --cc=holler@ahsoftware.de \ --cc=javier.martinez@collabora.co.uk \ --cc=jgchunter@gmail.com \ --cc=khilman@linaro.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=plagnioj@jcrosoft.com \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.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.