From: Sebastian Frias <sf84@laposte.net>
To: Marc Zyngier <marc.zyngier@arm.com>, Jason Cooper <jason@lakedaemon.net>
Cc: Mason <slash.tmp@free.fr>, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router
Date: Thu, 7 Jul 2016 14:16:25 +0200 [thread overview]
Message-ID: <577E4819.4010004@laposte.net> (raw)
In-Reply-To: <577D0C95.2000703@arm.com>
Hi Marc,
On 07/06/2016 03:50 PM, Marc Zyngier wrote:
>> I think that's where part the misunderstanding comes from.
>> IMHO the output line is not a direct function of the input line.
>> Any of the 64 IRQ lines entering the "old controller" (irq-tango.c) can be
>> routed to any of its 3 outputs.
>
> Then the current DT binding isn't properly describing the HW.
Ok, thanks, so it is not a good example then.
>> In a nutshell:
>> - "old controller": routes [0...N] => GIC inputs [2...4]
>> - "new controller": routes [0...M] => GIC inputs [0...23]
>>
>> So, when we think about it, if the "new DT" specified 24 domains, it would
>> be equivalent of the "old DT" with 3 domains, right?
>
> Indeed, but I consider the "old" binding to be rather misleading. It
> should have been described as a router too, rather than hardcoding
> things in DT. Granted, it doesn't matter much when you only have 3
> possible output lines. But with 24 outputs, that becomes much more relevant.
I see.
>> So, putting aside routing considerations and the discussion above, I think
>> a simpler question is: if the domains should not be described in the DT,
>> how can we define the IRQ sharing in the DT?
>
> You could have a set of sub-nodes saying something like this:
>
> mux-hint0 {
> inputs = <1 45 127>;
> }
>
> mux-hint1 {
> inputs = <2 33>;
> }
>
> (or maybe you can have that as direct properties, but you get the idea).
> Here, you have two output pins dedicated to muxed interrupts (assuming
> they are all level interrupts), and the last 22 can be freely allocated
> as direct routes.
>
Ok, I'll try to do that.
So, aside from the DT issues (that is, that it is describing domains),
would it be ok to create a domain for each of the outputs?
Because I was looking at:
- Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt
- drivers/irqchip/exynos-combiner.c
- arch/arm/boot/dts/exynos4210.dtsi
and what I see is that the DT basically list all outputs [0...15] connected
to the parent interrupt controller, although the driver does not creates
separate domains, just one. Then it attaches a chained handler for each of
the outputs. On the .map callback it attaches a irqchip to the domain.
There is also:
- Documentation/devicetree/bindings/arm/omap/crossbar.txt
- drivers/irqchip/irq-crossbar.c
- arch/arm/boot/dts/dra7.dtsi
This one creates a domain hierarchy linked to the parent domain and uses
irq_domain_alloc_irqs_parent() and irq_domain_set_hwirq_and_chip() to attach
a irqchip to the domain on the .alloc callback.
Both use a single domain, as opposed to irq-tango.c which creates 3 domains.
Right now irq-tango_v2.c is supposed to create one domain per output (if
so the DT says)
Are there guidelines regarding that?
Thanks in advance.
Best regards,
Sebastian
next prev parent reply other threads:[~2016-07-07 12:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 16:03 [RFC PATCH v1] irqchip: add support for SMP irq router Sebastian Frias
2016-07-04 12:11 ` Mason
2016-07-05 12:30 ` Sebastian Frias
2016-07-05 14:41 ` Jason Cooper
2016-07-05 15:07 ` Mason
2016-07-05 16:16 ` Jason Cooper
2016-07-06 11:37 ` Sebastian Frias
2016-07-06 16:28 ` Jason Cooper
2016-07-20 11:42 ` Sebastian Frias
2016-07-20 13:56 ` Jason Cooper
2016-07-05 15:18 ` Sebastian Frias
2016-07-05 15:53 ` Jason Cooper
2016-07-05 16:38 ` Sebastian Frias
2016-07-05 16:48 ` Marc Zyngier
2016-07-05 16:59 ` Sebastian Frias
2016-07-05 17:13 ` Marc Zyngier
2016-07-05 19:24 ` Thomas Gleixner
2016-07-06 8:58 ` Marc Zyngier
2016-07-06 9:30 ` Thomas Gleixner
2016-07-06 10:49 ` Sebastian Frias
2016-07-06 13:54 ` Marc Zyngier
2016-07-06 16:49 ` Jason Cooper
2016-07-06 10:47 ` Sebastian Frias
2016-07-06 13:50 ` Marc Zyngier
2016-07-07 12:16 ` Sebastian Frias [this message]
2016-07-07 12:42 ` Marc Zyngier
2016-07-19 14:23 ` [RFC PATCH v2] " Sebastian Frias
2016-07-19 16:49 ` Thomas Gleixner
2016-07-20 11:06 ` Sebastian Frias
2016-07-20 13:19 ` Marc Zyngier
2016-07-20 14:38 ` Thomas Gleixner
2016-07-20 9:35 ` Marc Gonzalez
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=577E4819.4010004@laposte.net \
--to=sf84@laposte.net \
--cc=jason@lakedaemon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=slash.tmp@free.fr \
--cc=tglx@linutronix.de \
/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).