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: Sat, 03 Aug 2013 09:23:39 +0200 [thread overview]
Message-ID: <51FCAFFB.4000005@ahsoftware.de> (raw)
In-Reply-To: <51FBD1CA.1000202@ahsoftware.de>
Am 02.08.2013 17:35, schrieb Alexander Holler:
> Am 02.08.2013 11:57, schrieb Alexander Holler:
>
>> 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()
Thinking again about what I've tried, I might have make the failure to
add the interrupt-parent line to the mmc-section (where the gpio was
specified) and not to the gpio(-controller) section where it might have
belong too (again, there was no example and no documentation).
But why I again bother you all with another mail, is that I don't like
the fact that the irq-flags might have to be specified in the DT and the
source (and they have to match).
A solution might be to use the flags specified in the DT for the
particular irq and ignore the flags specified as parameter to
request_irq(). At least as long as DT isn't mandatory. And in the
future, the flags could just be removed from the call to request_irq()
depending (then visible too) only on the flags as specified in the DT.
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: Sat, 03 Aug 2013 09:23:39 +0200 [thread overview]
Message-ID: <51FCAFFB.4000005@ahsoftware.de> (raw)
In-Reply-To: <51FBD1CA.1000202@ahsoftware.de>
Am 02.08.2013 17:35, schrieb Alexander Holler:
> Am 02.08.2013 11:57, schrieb Alexander Holler:
>
>> 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()
Thinking again about what I've tried, I might have make the failure to
add the interrupt-parent line to the mmc-section (where the gpio was
specified) and not to the gpio(-controller) section where it might have
belong too (again, there was no example and no documentation).
But why I again bother you all with another mail, is that I don't like
the fact that the irq-flags might have to be specified in the DT and the
source (and they have to match).
A solution might be to use the flags specified in the DT for the
particular irq and ignore the flags specified as parameter to
request_irq(). At least as long as DT isn't mandatory. And in the
future, the flags could just be removed from the call to request_irq()
depending (then visible too) only on the flags as specified in the DT.
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: Sat, 03 Aug 2013 09:23:39 +0200 [thread overview]
Message-ID: <51FCAFFB.4000005@ahsoftware.de> (raw)
In-Reply-To: <51FBD1CA.1000202@ahsoftware.de>
Am 02.08.2013 17:35, schrieb Alexander Holler:
> Am 02.08.2013 11:57, schrieb Alexander Holler:
>
>> 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()
Thinking again about what I've tried, I might have make the failure to
add the interrupt-parent line to the mmc-section (where the gpio was
specified) and not to the gpio(-controller) section where it might have
belong too (again, there was no example and no documentation).
But why I again bother you all with another mail, is that I don't like
the fact that the irq-flags might have to be specified in the DT and the
source (and they have to match).
A solution might be to use the flags specified in the DT for the
particular irq and ignore the flags specified as parameter to
request_irq(). At least as long as DT isn't mandatory. And in the
future, the flags could just be removed from the call to request_irq()
depending (then visible too) only on the flags as specified in the DT.
Regards,
Alexander Holler
next prev parent reply other threads:[~2013-08-03 7:24 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 [this message]
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=51FCAFFB.4000005@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.