[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5231A791.9080600@ahsoftware.de>
Date: Thu, 12 Sep 2013 13:37:53 +0200
From: Alexander Holler <holler@...oftware.de>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
CC: Linus Walleij <linus.walleij@...aro.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Grant Likely <grant.likely@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux-OMAP <linux-omap@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Enric Balletbo i Serra <eballetbo@...il.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Santosh Shilimkar <santosh.shilimkar@...com>,
Kevin Hilman <khilman@...aro.org>,
Balaji T K <balajitk@...com>,
Tony Lindgren <tony@...mide.com>,
Jon Hunter <jgchunter@...il.com>
Subject: Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 13:26, schrieb Alexander Holler:
> 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:
>>>
...
>>>
>>>> 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";
>
And looking at how gpios are defined, I think it should be like that:
interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH
&gpio7 2 IRQF_TRIGGER_LOW
>;
interrupt-names = "foo", "bar";
So without that interrupt-parent.
Regards,
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists