From: holler@ahsoftware.de (Alexander Holler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Date: Thu, 12 Sep 2013 13:26:54 +0200 [thread overview]
Message-ID: <5231A4FE.1070704@ahsoftware.de> (raw)
In-Reply-To: <5231A0F8.1070505@ahsoftware.de>
Am 12.09.2013 13:09, schrieb Alexander Holler:
> Am 12.09.2013 12:28, schrieb Alexander Holler:
>> Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
>>> On 09/12/2013 10:55 AM, Alexander Holler wrote:
>>
>> ...
>>>>
>>>> By the way, how do you define two GPIOs/IRQs from different
>>>> gpio-banks/irq-controllers wuth that scheme?
>>>>
>>>
>>> That is indeed a very good question and I don't have a definite answer.
>>>
>>>> Would that be like below?
>>>>
>>>> ethernet at 5,0 {
>>>> compatible = "smsc,lan9221", "smsc,lan9115";
>>>> interrupt-parent = <&gpio6>;
>>>> interrupts = <16 8>;
>>>> interrupt-parent = <&gpio7>;
>>>> interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
>>>> };
>>>>
>>
>> ...
>>
>>> So, if I understood the code correctly the DT IRQ core doesn't expect
>>> a device
>>> node to have more than one "interrupt-parent" property.
>>>
>>> It *should* work though if you have multiple "interrupts" properties
>>> defined and
>>> all of them have the same "interrupt-parent":
>>>
>>> interrupt-parent = <&gpio6>;
>>> interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
>>> interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */
>>>
>>> since of_irq_map_one() will be called for each "interrupts" and the
>>> correct
>>> "interrupt-parent" will get obtained by of_irq_find_parent().
>>
>> I assumed that answer. So to make such a scenario possible, something
>> like this might be neccessary:
>>
>> interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
>> interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */
>>
>> or, to be compatible
>>
>> interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
>> interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
>>
>> Another problem is the naming. In all the above cases, the driver would
>> not know which IRQ he should use for what. Maybe the order defines it,
>> but that wouldn't be very verbose. And I think just changing the name
>> would make travelling the tree impossible, as only the driver itself
>> would know the name and it's meaning.
>
> On a second look, travelling the tree is still possible if the solution
> would be like above (without that interrupt-parent). So if a driver
> requires two interrupts he could use
>
> interrupt-foo = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
> interrupt-bar = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
>
> And travelling the tree will still be possible because walking from the
> interrupt-controllers (those gpio) downwards would end up at the
> interrupt definitions, so the name of them isn't needed to find them in
> the tree.
I've just seen how they solved it for dma:
dmas = <&edma0 16
&edma0 17>;
dma-names = "rx", "tx";
so it would be like
interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
interrupt-names = "foo", "bar";
Or this would be possible:
interrupt-parent = <&gpio6 &gpio7>;
interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW>; /* GPIO7_1 */
interrupt-names = "foo", "bar";
Regards,
Alexander
next prev parent reply other threads:[~2013-09-12 11:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1375101368-17645-1-git-send-email-linus.walleij@linaro.org>
2013-07-30 4:30 ` [PATCH] RFC: interrupt consistency check for OF GPIO IRQs Grant Likely
2013-07-30 23:44 ` Linus Walleij
2013-07-31 8:35 ` Javier Martinez Canillas
2013-08-02 9:57 ` Alexander Holler
2013-08-02 15:35 ` Alexander Holler
2013-08-03 7:23 ` Alexander Holler
2013-09-10 7:00 ` Joel Fernandes
2013-09-10 13:17 ` Javier Martinez Canillas
2013-09-10 15:00 ` Joel Fernandes
2013-09-10 15:48 ` Javier Martinez Canillas
2013-09-10 16:25 ` Joel Fernandes
2013-09-11 7:05 ` Alexander Holler
2013-09-11 7:16 ` Alexander Holler
2013-09-11 7:30 ` Alexander Holler
2013-09-11 7:36 ` Alexander Holler
2013-08-13 9:52 ` Lars Poeschel
2013-08-19 22:04 ` Laurent Pinchart
2013-08-21 22:02 ` Linus Walleij
2013-09-06 15:32 ` Laurent Pinchart
2013-09-11 15:30 ` Alexander Holler
2013-09-11 16:14 ` Javier Martinez Canillas
2013-09-11 17:42 ` Alexander Holler
2013-09-12 8:55 ` Alexander Holler
2013-09-12 10:11 ` Javier Martinez Canillas
2013-09-12 10:28 ` Alexander Holler
2013-09-12 11:09 ` Alexander Holler
2013-09-12 11:26 ` Alexander Holler [this message]
2013-09-12 11:37 ` Alexander Holler
2013-09-12 15:19 ` Stephen Warren
2013-09-12 15:57 ` Alexander Holler
2013-09-18 0:36 ` Grant Likely
2013-10-20 12:41 ` Laurent Pinchart
2013-10-20 15:51 ` Tony Lindgren
2013-10-20 21:35 ` Stephen Warren
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=5231A4FE.1070704@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).