linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 6 Jul 2016 12:47:58 +0200	[thread overview]
Message-ID: <577CE1DE.6080502@laposte.net> (raw)
In-Reply-To: <577BEABE.2010204@arm.com>

Hi Marc,

On 07/05/2016 07:13 PM, Marc Zyngier wrote:
>>> You really don't need to describe this. The configuration that is
>>> applied to your router in entirely under software control,
>>
>> With "entirely under software control" do you mean this driver's code?
> 
> Yes.

Ok.

> 
>>
>>> and none of
>>> that should appear in the DT. You could decide to mux all the interrupts
>>> to a single one, or decide that the 23 first interrupts you discover get
>>> their own private line to the GIC and that everything else is muxed.
>>>
>>> So given that this is completely defined by software, it has no place in
>>> DT. 
>>
>> I think I'm missing something, what is the difference between the domains
>> described by nodes in the DT for irq-tango.c (arch/arm/boot/dts/tango4-common.dtsi)
>> and the DT from my RFC?
> 
> The fundamental difference is that with your new fancy controller, you
> can decide what is going where, while the previous one is completely set
> in stone (the output line is a direct function of the input line).

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.
The only thing fixed is which GIC input is connected to those 3 outputs, ie:
GIC inputs 2, 3 and 4.

In the the "new controller" (irq-tango_v2.c, this RFC), any of 128 IRQ lines
can be routed to any of 24 outputs, connected to GIC inputs 0...23.

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?

That's why it seemed more or less natural to keep describing the domains in
the DT, the main reason for that being that it allowed the user to specify
the IRQ sharing in the DT, and this is precisely the key point of this.

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?

Best regards,

Sebastian

  parent reply	other threads:[~2016-07-06 10:48 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 [this message]
2016-07-06 13:50                     ` Marc Zyngier
2016-07-07 12:16                       ` Sebastian Frias
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=577CE1DE.6080502@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).