* interrupts or interrupts-extended ?
@ 2015-04-30 5:57 Masahiro Yamada
[not found] ` <CAK7LNATcFzCV_3uaOnRDHLb=A+TPPDUeAoH_1QTUZDxYAB7VDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: Masahiro Yamada @ 2015-04-30 5:57 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Hello, device tree folks,
Can I ask a little piece of advice?
Which is a preferred way for specifying an interrupt property,
interrupt-parent & interrupts, or interrupts-extended ?
There is only one interrupt controller on my SoC,
so I think either should work enough for me.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: interrupts or interrupts-extended ?
[not found] ` <CAK7LNATcFzCV_3uaOnRDHLb=A+TPPDUeAoH_1QTUZDxYAB7VDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-04-30 7:37 ` Arnd Bergmann
2015-05-07 4:19 ` Masahiro Yamada
0 siblings, 1 reply; 3+ messages in thread
From: Arnd Bergmann @ 2015-04-30 7:37 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
On Thursday 30 April 2015 14:57:19 Masahiro Yamada wrote:
> Hello, device tree folks,
>
>
> Can I ask a little piece of advice?
>
> Which is a preferred way for specifying an interrupt property,
> interrupt-parent & interrupts, or interrupts-extended ?
>
>
> There is only one interrupt controller on my SoC,
> so I think either should work enough for me.
>
interrupts is well-understood by more people, I would pick that one normally,
unless there is a need.
The main purpose of interrupts-extended is to allow one device to have
multiple interrupts that are handled by different controllers, without
introducing a (more complex) interrupt-map property in the parent.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: interrupts or interrupts-extended ?
2015-04-30 7:37 ` Arnd Bergmann
@ 2015-05-07 4:19 ` Masahiro Yamada
0 siblings, 0 replies; 3+ messages in thread
From: Masahiro Yamada @ 2015-05-07 4:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
Hi Arnd,
2015-04-30 16:37 GMT+09:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Thursday 30 April 2015 14:57:19 Masahiro Yamada wrote:
>> Hello, device tree folks,
>>
>>
>> Can I ask a little piece of advice?
>>
>> Which is a preferred way for specifying an interrupt property,
>> interrupt-parent & interrupts, or interrupts-extended ?
>>
>>
>> There is only one interrupt controller on my SoC,
>> so I think either should work enough for me.
>>
>
> interrupts is well-understood by more people, I would pick that one normally,
> unless there is a need.
>
> The main purpose of interrupts-extended is to allow one device to have
> multiple interrupts that are handled by different controllers, without
> introducing a (more complex) interrupt-map property in the parent.
OK, I will use interrupt-parent & interrupts.
Thanks for you advice!
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-07 4:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-30 5:57 interrupts or interrupts-extended ? Masahiro Yamada
[not found] ` <CAK7LNATcFzCV_3uaOnRDHLb=A+TPPDUeAoH_1QTUZDxYAB7VDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-30 7:37 ` Arnd Bergmann
2015-05-07 4:19 ` Masahiro Yamada
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox