[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 16:09:19 Arnd Bergmann wrote:
> > Hi JC,
> >
> > Thanks for sending out this patch, I know people have been waiting
> > for it. I never understood how it's wired and how it should be
> > in the device-tree, this makes things much clearer.
> >
> > I think the mpic device node actually should be changed to point to
> > the c3po as its parent, but that would mean that you can't boot
> > an old linux kernel on a new device tree, because the code to
> > handle c3po is missing there.
> >
> > Is the priority the only way you can distinguish mpic interrupts
> > from non-mpic ones?
> 
> The programmable parts for a C3PO interrupt are: class, destination node, 
> destination thread on the node and priority. The SLOF firmware just change 
> the prirority for the 4 possible interrupts generated by the C3PO (MPIC 
> machine check = 0, MPIC critical = 4, direct MBX = 8, MPIC normal = c).
> 
> According to the Cell manual, class = 2 is correct for external interrupts. 
> Class 0 and 1 are reserved for internal SPU/DMA error/translation cases. 3 is 
> reserved.

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.

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.

> > Please open a bug report against the device tree when there is something
> > missing. It's much easier to fix it in the right place than to keep
> > ugly hacks around.
> >
> > Since CAB is now an official product, I wonder how such an obvious bug
> > could slip through QA testing...
> 
> Well I asked the question at the time the device tree was submited to us but I 
> was told there was no consensus in the firmware team on how to handle the MBX 
> direct interrupt because it was not a usual MPIC and therefore it was 
> intentionaly left out.

If you have the name of the person that gave you such an answer, please
tell me in a private mail!

If it's not in the device tree, we don't use it. The people that are
responsible for the device tree should know that.

> > This is the wrong place for it, the IIC code should not need to know
> > about specific external interrupt controllers.
> 
> Well sorry about it but this is the only place where I can check priority.

That can be changed if necessary. If we have another cascaded interrupt
controller (mpic behind c3p0), the c3p0 code should check the actual source.
If we can differentiate by class, then we don't even need that, as the
number will be different to start with.

> > This is wrong, the hw_int and iic_int numbers should come from the
> > "interrupts" and "interrupt-parent" property of the device node you are
> > looking at.
> 
> Well there is none for the direct MBX interrupt, so I had to make one. I am 
> hardcoding it to 128 (MPIC external interrupts) + 4 (MPIC IPIs) + 4 (MPIC 
> timers) = 136. Then I have to distinguish between IOIF0 (CAB case) and IOIF1 
> (Malta case).

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

	Arnd <><