From: Alexander Holler <holler@ahsoftware.de>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>,
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>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
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: Fri, 02 Aug 2013 11:57:38 +0200 [thread overview]
Message-ID: <51FB8292.9090000@ahsoftware.de> (raw)
In-Reply-To: <51F8CC35.1070704@collabora.co.uk>
Am 31.07.2013 10:35, schrieb Javier Martinez Canillas:
>
> The problem is that board files and drivers that has not not been completed
> migrated to DT assumes (at least for OMAP) that *every* GPIO line is mapped as
> an IRQ and they just do:
>
> gpio_request(gpio,...);
> gpio_direction_input()
> request[_threaded]_irq(gpio_to_irq(gpio), ...);
>
> My patch-set changed the gpio-omap driver to not map all GPIO lines but only the
> ones that were really used as an IRQ and let the DT core to do the mapping from
> irq_create_of_mapping(). The first problem reported with the OMAP patch was that
> a driver was using the above sequence and that the GPIO had not been mapped.
> This user was booting with DT and so this showed a bug in the driver and a DT
> that did not conform with the standard schema used in mainline but this shows a
> potential issue.
There must have been a bug in the patch too. I've also added that
iinterrupt-parent stuff (with the same flags as used by the driver) and
just have let the driver call
request_threaded_irq(gpio_to_irq(gpio), flags);
without the gpio_request()/input() before. And request_threaded_irq()
returned -EBUSY. I'm pretty sure nothing else did use that gpio, but I
haven't looked at why request_threaded_irq() returned -EBUSY. I assume
the new mapping stuff did reserve the irq in such a way, that the driver
couldn't request the IRQ.
Otherwise I wouldn't have had a problem by just adding the necessary
entries to the DT.
But I have to say I didn't like the syntax too, and it wasn't obvious
how the syntax is and how to conclude from a gpio number to an
irq-number and the patch didn't really include some documentation or
useful example.
Regards,
Alexander Holler
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Holler <holler@ahsoftware.de>
To: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>, Balaji T K <balajitk@ti.com>,
Enric Balletbo i Serra <eballetbo@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Grant Likely <grant.likely@linaro.org>,
Linux-OMAP <linux-omap@vger.kernel.org>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Jon Hunter <jgchunter@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Date: Fri, 02 Aug 2013 11:57:38 +0200 [thread overview]
Message-ID: <51FB8292.9090000@ahsoftware.de> (raw)
In-Reply-To: <51F8CC35.1070704@collabora.co.uk>
Am 31.07.2013 10:35, schrieb Javier Martinez Canillas:
>
> The problem is that board files and drivers that has not not been completed
> migrated to DT assumes (at least for OMAP) that *every* GPIO line is mapped as
> an IRQ and they just do:
>
> gpio_request(gpio,...);
> gpio_direction_input()
> request[_threaded]_irq(gpio_to_irq(gpio), ...);
>
> My patch-set changed the gpio-omap driver to not map all GPIO lines but only the
> ones that were really used as an IRQ and let the DT core to do the mapping from
> irq_create_of_mapping(). The first problem reported with the OMAP patch was that
> a driver was using the above sequence and that the GPIO had not been mapped.
> This user was booting with DT and so this showed a bug in the driver and a DT
> that did not conform with the standard schema used in mainline but this shows a
> potential issue.
There must have been a bug in the patch too. I've also added that
iinterrupt-parent stuff (with the same flags as used by the driver) and
just have let the driver call
request_threaded_irq(gpio_to_irq(gpio), flags);
without the gpio_request()/input() before. And request_threaded_irq()
returned -EBUSY. I'm pretty sure nothing else did use that gpio, but I
haven't looked at why request_threaded_irq() returned -EBUSY. I assume
the new mapping stuff did reserve the irq in such a way, that the driver
couldn't request the IRQ.
Otherwise I wouldn't have had a problem by just adding the necessary
entries to the DT.
But I have to say I didn't like the syntax too, and it wasn't obvious
how the syntax is and how to conclude from a gpio number to an
irq-number and the patch didn't really include some documentation or
useful example.
Regards,
Alexander Holler
WARNING: multiple messages have this Message-ID (diff)
From: holler@ahsoftware.de (Alexander Holler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Date: Fri, 02 Aug 2013 11:57:38 +0200 [thread overview]
Message-ID: <51FB8292.9090000@ahsoftware.de> (raw)
In-Reply-To: <51F8CC35.1070704@collabora.co.uk>
Am 31.07.2013 10:35, schrieb Javier Martinez Canillas:
>
> The problem is that board files and drivers that has not not been completed
> migrated to DT assumes (at least for OMAP) that *every* GPIO line is mapped as
> an IRQ and they just do:
>
> gpio_request(gpio,...);
> gpio_direction_input()
> request[_threaded]_irq(gpio_to_irq(gpio), ...);
>
> My patch-set changed the gpio-omap driver to not map all GPIO lines but only the
> ones that were really used as an IRQ and let the DT core to do the mapping from
> irq_create_of_mapping(). The first problem reported with the OMAP patch was that
> a driver was using the above sequence and that the GPIO had not been mapped.
> This user was booting with DT and so this showed a bug in the driver and a DT
> that did not conform with the standard schema used in mainline but this shows a
> potential issue.
There must have been a bug in the patch too. I've also added that
iinterrupt-parent stuff (with the same flags as used by the driver) and
just have let the driver call
request_threaded_irq(gpio_to_irq(gpio), flags);
without the gpio_request()/input() before. And request_threaded_irq()
returned -EBUSY. I'm pretty sure nothing else did use that gpio, but I
haven't looked at why request_threaded_irq() returned -EBUSY. I assume
the new mapping stuff did reserve the irq in such a way, that the driver
couldn't request the IRQ.
Otherwise I wouldn't have had a problem by just adding the necessary
entries to the DT.
But I have to say I didn't like the syntax too, and it wasn't obvious
how the syntax is and how to conclude from a gpio number to an
irq-number and the patch didn't really include some documentation or
useful example.
Regards,
Alexander Holler
next prev parent reply other threads:[~2013-08-02 9:59 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 [this message]
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
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=51FB8292.9090000@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=balajitk@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=eballetbo@gmail.com \
--cc=grant.likely@linaro.org \
--cc=javier.martinez@collabora.co.uk \
--cc=jgchunter@gmail.com \
--cc=khilman@linaro.org \
--cc=linus.walleij@linaro.org \
--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: link
Be 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.