Re: Using irq-crossbar.c

From: Marc Zyngier <marc.zyngier@arm.com>
To: Mason <slash.tmp@free.fr>
Cc: Sebastian Frias <sf84@laposte.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Mans Rullgard <mans@mansr.com>
Subject: Re: Using irq-crossbar.c
Date: Mon, 13 Jun 2016 08:58:33 +0100	[thread overview]
Message-ID: <575E67A9.9020003@arm.com> (raw)
In-Reply-To: <575D689E.9080205@free.fr>

On 12/06/16 14:50, Mason wrote:
> On 12/06/2016 12:00, Marc Zyngier wrote:
> 
>> Mason wrote:
>>
>>> The problem with some Linux APIs is that they're logical and obvious
>>> to people who've been using them for years. For newcomers, it's not
>>> always so obvious.
>>>
>>> In this specific instance, the problem statement seems rather simple,
>>> on the surface. An interrupt controller, X=0..127 lines in, Y=0..23
>>> lines out (connected to GIC interrupt lines 0..23) and "all" we need
>>> is a way to map Xs to Ys.
>>>
>>> As a first order approximation, it's enough to map all Xs to 0.
>>> And provide a way for the kernel to check the registers containing
>>> the bit-vectors indicating which interrupt(s) fired.
>>
>> If that's what your hardware is, then you are taking the wrong
>> approach. The irq-crossbar driver does not do that at all: it has x
>> inputs and y outputs, but connects exactly *one input to one output*.
>> No multiplexing.
> 
> Connecting one input to one output is possible iff x=y right?
> (In other words, a bijection.)

It is *always* possible to connect anything to anything else. You were
assuming that this particular driver was fitting your particular case,
and it is obvious that it is not (iow: the crossbar transformation
cannot be surjective).

>> And the hierarchical domain infrastructure enforces a similar property:
>> a Linux interrupt is dealt with at each level of the hierarchy without
>> multiplexing: the "irq" is the same, while the "hwirq" varies to
>> reflect the "input pin" for a given interrupt controller.
>>
>> In your particular case, you have an evolved chained interrupt
>> controller, and nothing else.
> 
> Is it possible to support such an "evolved chained intc" through DT only,
> or does it require a few function calls from driver code?

There is no such thing as "DT only". You will have to do some actual
irqchip development.

>>>> - You've changed the default interrupt controller to be your crossbar.
>>>>   Which means that all the sub-nodes are inheriting it. Have you
>>>>   checked that this was valid for all of these nodes?
>>>
>>> I'm not sure I follow. All platform interrupts flow into the platform
>>> controller. Maybe other platforms have more complex setups, with
>>> several cascaded controllers?
>>
>> Most embedded platforms do.
> 
> My imagination is lacking, I don't see why it needs to be more
> complex than N platform input lines, and M output lines feeding
> into the GIC (with M <= N)

It is not more complex. It is different.

	M.
-- 
Jazz is not dead. It just smells funny...