[Cbe-oss-dev] [RFC/PATCH] adding support for direct MBX interrupt on Axon based platform.

[Arnd Bergmann]

On Friday 18 May 2007, Jean-Christophe Dubois wrote:
> On Friday 18 May 2007 17:54:58 Arnd Bergmann wrote:
> > What about the source unit number? Since the mailbox is obviously a
> > different entity from the mpic, you should be able to program it to a
> > different source node/unit.
> 
> The Axon doesn't set it. From the Cell perspective the interrupt comes from 
> one particular IOIF, that's it. The Cell hardware/code knows the unit that 
> generated the interrupt. Either IOIF0 (unit = 0) or IOIF1 (unit = 0xb). So 
> what I am programming on the C3PO doesn't show on the Cell. This is just so 
> that the interrupt packet is routed to the correct location. All interrupt 
> packets from the C3PO (MPIC or MBX) will come from the same "unit". You can't 
> choose this. What could differ are class and priority. 

ok

> You could also decide  
> to target the other PPU thread (all MPIC interrupts to one thread, MBX 
> interrupt to the other thread).

nah, that sounds even more fishy, I'm still hoping for a fixed version
of AXON that will actually be able to distribute interrupts to the
different threads, which would break such a concept.
 
> > I wouldn't really mind using a different class here if that's the only
> > way we can really tell, even if that is not in the spirit of the CBE
> > architecture.
> 
> Well that might be a solution but I didn't want to go this way because it was 
> diverging from the CBE architecture document. Now if we go this route, we 
> will have to make sure there is no collision with some already valid 
> interrupts. I guess the unit should set the interrupt apart already.

I can't see anything in the CBE Architecture docs that mentions specific
definitions of class values together with I/O interrupts, only SPE/MFC
interrupts have a clear definition in this regard. Is there any specific
section in the documentation that you refer to?
 
> We could also factorise somehow the interrupt priority in the hw interrupt 
> number. But I guess that would make a lot of changes.

Yes, it would make the device tree incompatible because the existing
interrupt numbers would need to change.

> > But the number of the mailbox interrupt is in a different domain from the
> > mpic interrupt, as the interrupts don't go to the mpic at all.
> 
> True and the interrupt doesn't go through the MPIC at all. And just to make 
> things clear the MBX direct interrupt is not handled by the MPIC code at 
> all ...

yes, that was my point. You don't need to number the interrupt 136, it
can simply have number zero all the time, since it's distinguished by
the irq_host pointer, which you pass to irq_create_mapping().
 
> > You can't 
> > just make up numbers like that, we've been through that pain before on
> > the QS20. The interrupt number needs to be allocated by the
> > irq_of_parse_and_map() function now.
> 
> Well obviously, I can't use this function for the direct MBX and my driver 
> code has to account for this when dealing with MBX direct interrupt. All 
> other interrupts are allocated with the the normal irq_of_parse_and_map() 
> method when run on the CAB or Malta blade.
> 
> I agree that I should avoid to do this but I nedded something that work as the 
> MPIC indirect MBX interrupt is broken on Axon 1.1. Only direct interrupts are 
> reliable and it is not part of the device tree.

The real solution is to fix the device tree so that the mailbox device points
to the c3p0 as its interrupt parent, instead of the mpic device. Then
irq_of_parse_and_map will return give you a route to the direct interrupt.

	Arnd <><