Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420887 > unrolled thread

Re: Using irq-crossbar.c

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Using irq-crossbar.c "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca> - 2016-06-13 16:10 +0200
    Re: Using irq-crossbar.c Sebastian Frias <sf84@laposte.net> - 2016-06-13 17:00 +0200
      Re: Using irq-crossbar.c "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca> - 2016-06-13 17:50 +0200
        Re: Using irq-crossbar.c Marc Zyngier <marc.zyngier@arm.com> - 2016-06-13 18:00 +0200
        Re: Using irq-crossbar.c Mason <slash.tmp@free.fr> - 2016-06-13 18:00 +0200
          Re: Using irq-crossbar.c "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca> - 2016-06-13 20:00 +0200

#1420887 — Re: Using irq-crossbar.c

On Sat, Jun 11, 2016 at 05:37:51PM +0200, Mason wrote:
> Only the name of the file was provided, not the path. I was not aware
> that you already knew where to find it. I made no claim whatsoever on
> the implementation. In fact, I agree with everything Lennart wrote.

The way the TI irq crossbar works is:

You have say 200 interrupt sources in the system.  You have some
coprocessor (say PRU0) that you want to handle UART7, so you tell the
crossbar: Please map the IRQ from UART7 (which might be input 146 on the
crossbar) to IRQ 10 on the PRU0 processor.  Now whenever the interrupt
from UART7 fires, PRU0 will see it as IRQ10.  There are no interrupt
registers to check in the crossbar, it is purely virtual wires for
routing interrupts.  It just happens to be an enourmouse and very very
flexible set of wires.

If on the other hand you have 128 inputs and 24 outputs and you want
all 128 inputs to work, and you have 24 128bit registers in the device
to tell you which of the inputs fired to cause a given output to fire,
then you in fact have an interrupt controller, not a crossbar.  This would
be much more similar to how the original x86 design has an i8259 connected
with 8 inputs and 1 output to an input on a second i8259 (the output of
the secondary chip connects to IRQ2 on the primary).  You actually need
an irq controller driver to go read the registers to determine which
external interrupt fired and to assign a virtual IRQ number so that
drivers can register for a given externel pin.  Cascaded interrupt
controllers like this is perfectly common on lots of systems.

Now of course you could cheat and simply declare that all the inputs
that are mixed to a single output are in fact sharing a single interrupt
(fine if they are level triggered, could be problematic if edge triggered,
depending on how it works exactly).  Of course then when an interrupt
happens, every driver that handles some device on a given shared interrupt
will have the handler called in turn until everyone has had a change
to handle the interrupt, at which point everyone should have stopped
triggering it and it will clear itself, unless of course another event
happened on one of the devices in which case another loop through everyone
happens to handle the new events.  The loop will continue until the
interrupt clears, as long as some of the handlers return that they in fact
did do some work to handle the interrupt event.  If no one claims to have
done something and the interrupt stays, you get the kernel killing the
interrupt with a message about "Interrupt foo happened and nobody cared".

> 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?

I get the impression yours is not as simple as you thought either.

-- 
len Sorensen

[toc] | [next] | [standalone]

#1420960

Hi Lennart,

Thanks for your input, please find my comments below.

On 06/13/2016 04:04 PM, Lennart Sorensen wrote:
> On Sat, Jun 11, 2016 at 05:37:51PM +0200, Mason wrote:
>> Only the name of the file was provided, not the path. I was not aware
>> that you already knew where to find it. I made no claim whatsoever on
>> the implementation. In fact, I agree with everything Lennart wrote.
> 
> The way the TI irq crossbar works is:
> 
> You have say 200 interrupt sources in the system.  You have some
> coprocessor (say PRU0) that you want to handle UART7, so you tell the
> crossbar: Please map the IRQ from UART7 (which might be input 146 on the
> crossbar) to IRQ 10 on the PRU0 processor.  Now whenever the interrupt
> from UART7 fires, PRU0 will see it as IRQ10.  There are no interrupt
> registers to check in the crossbar, it is purely virtual wires for
> routing interrupts.  It just happens to be an enourmouse and very very
> flexible set of wires.
> 

Ok, thanks for the information.

> If on the other hand you have 128 inputs and 24 outputs and you want
> all 128 inputs to work, and you have 24 128bit registers in the device
> to tell you which of the inputs fired to cause a given output to fire,
> then you in fact have an interrupt controller, not a crossbar. 

Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the GIC.
The HW block is a many-to-many router.
There are 128 32bit registers which specify, for each of the corresponding 128 inputs, to which of the 24 outputs it would be routed to.

There are 4 32bit registers that can show the RAW status of the 128 inputs, but they do not latch on the inputs.
That's why our understanding is that on Linux terms it is not an interrupt controller, but just a many-to-many mux, the only real interrupt-controller (where one can set if the line is active high or low for example) is the GIC.

> This would
> be much more similar to how the original x86 design has an i8259 connected
> with 8 inputs and 1 output to an input on a second i8259 (the output of
> the secondary chip connects to IRQ2 on the primary).  You actually need
> an irq controller driver to go read the registers to determine which
> external interrupt fired and to assign a virtual IRQ number so that
> drivers can register for a given externel pin.  Cascaded interrupt
> controllers like this is perfectly common on lots of systems.

Thanks for the background on the i8259 and the cascaded interrupts.
However, our understanding is that it would only be required if more than 24 devices request IRQ lines, in which case, some of them would have to share a single GIC IRQ line, right?
Shall we worry about that now?

> 
> Now of course you could cheat and simply declare that all the inputs
> that are mixed to a single output are in fact sharing a single interrupt
> (fine if they are level triggered, could be problematic if edge triggered,
> depending on how it works exactly).  Of course then when an interrupt
> happens, every driver that handles some device on a given shared interrupt
> will have the handler called in turn until everyone has had a change
> to handle the interrupt, at which point everyone should have stopped
> triggering it and it will clear itself, unless of course another event
> happened on one of the devices in which case another loop through everyone
> happens to handle the new events.  The loop will continue until the
> interrupt clears, as long as some of the handlers return that they in fact
> did do some work to handle the interrupt event.  If no one claims to have
> done something and the interrupt stays, you get the kernel killing the
> interrupt with a message about "Interrupt foo happened and nobody cared".

This is interesting.
We have one interrupt controller already upstream, drivers/irqchip/irq-tango.c, and our understanding is that it dispatches one IRQ at the time, see tangox_dispatch_irqs() function, is that what you are discussing?

Best regards,

Sebastian

[toc] | [prev] | [next] | [standalone]

#1421010

On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the GIC.
> The HW block is a many-to-many router.
> There are 128 32bit registers which specify, for each of the corresponding 128 inputs, to which of the 24 outputs it would be routed to.
> 
> There are 4 32bit registers that can show the RAW status of the 128 inputs, but they do not latch on the inputs.
> That's why our understanding is that on Linux terms it is not an interrupt controller, but just a many-to-many mux, the only real interrupt-controller (where one can set if the line is active high or low for example) is the GIC.

Well that does just sound like a mux.  But that does mean you either
can't use more than 24 inputs at once, or you will be sharing interrupts.

I really hate shared interrutps so I would never design something that
way, but it is simpler.

> Thanks for the background on the i8259 and the cascaded interrupts.
> However, our understanding is that it would only be required if more than 24 devices request IRQ lines, in which case, some of them would have to share a single GIC IRQ line, right?
> Shall we worry about that now?

Well if you are sure you never need more than 24 devices registered at
once, then it shouldn't be a problem.

> This is interesting.
> We have one interrupt controller already upstream, drivers/irqchip/irq-tango.c, and our understanding is that it dispatches one IRQ at the time, see tangox_dispatch_irqs() function, is that what you are discussing?

That does look like a proper interrupt controller that could be cascaded
of another one if needed.

-- 
Len Sorensen

[toc] | [prev] | [next] | [standalone]

#1421023

On 13/06/16 16:49, Mason wrote:
> On 13/06/2016 17:42, Lennart Sorensen wrote:
>> On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
>>> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the GIC.
>>> The HW block is a many-to-many router.
>>> There are 128 32bit registers which specify, for each of the corresponding 128 inputs, to which of the 24 outputs it would be routed to.
>>>
>>> There are 4 32bit registers that can show the RAW status of the 128 inputs, but they do not latch on the inputs.
>>> That's why our understanding is that on Linux terms it is not an interrupt controller, but just a many-to-many mux, the only real interrupt-controller (where one can set if the line is active high or low for example) is the GIC.
>>
>> Well that does just sound like a mux.  But that does mean you either
>> can't use more than 24 inputs at once, or you will be sharing interrupts.
>>
>> I really hate shared interrupts so I would never design something that
>> way, but it is simpler.
> 
> If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.

Up to 224 SPIs actually, plus 16 PPIs.

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

[toc] | [prev] | [next] | [standalone]

#1421030

On 13/06/2016 17:42, Lennart Sorensen wrote:
> On Mon, Jun 13, 2016 at 04:57:13PM +0200, Sebastian Frias wrote:
>> Actually we have 128 inputs and 24 outputs, the 24 outputs go straight to the GIC.
>> The HW block is a many-to-many router.
>> There are 128 32bit registers which specify, for each of the corresponding 128 inputs, to which of the 24 outputs it would be routed to.
>>
>> There are 4 32bit registers that can show the RAW status of the 128 inputs, but they do not latch on the inputs.
>> That's why our understanding is that on Linux terms it is not an interrupt controller, but just a many-to-many mux, the only real interrupt-controller (where one can set if the line is active high or low for example) is the GIC.
> 
> Well that does just sound like a mux.  But that does mean you either
> can't use more than 24 inputs at once, or you will be sharing interrupts.
> 
> I really hate shared interrupts so I would never design something that
> way, but it is simpler.

If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.

So any SoC with more than 32 devices capable of generating IRQs
would have to share interrupts, right?

Regards.

[toc] | [prev] | [next] | [standalone]

#1421076

On Mon, Jun 13, 2016 at 05:49:55PM +0200, Mason wrote:
> If I am not mistaken, the Cortex A9 MPCore GIC has 32 inputs.
> 
> So any SoC with more than 32 devices capable of generating IRQs
> would have to share interrupts, right?

No, you simply add another interrupt controller to cascade it.  That way
every device can still have one interrupt it owns.

One interrupt on the GIC is owned by the second interrupt controller,
and its driver determines which actual external interrupt occured.

It is only shared when there is no way to determine which device caused
a given interrupt to happen and you have to ask every one of the devices
sharing it if they caused it.

-- 
Len Sorensen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web