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

[Benjamin Herrenschmidt]

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

We can't change the source but we can program a different class. I think
that might be an acceptable violation of the spec.

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

Yup.

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

I think the C3PO is just a bridge to generate iic interrupts, I don't
think it should appear as a PIC per-se.

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

Yes, the mailbox interrupt is basically the same as the upstream MPIC
interrupt. If we can change the class, we'll get a new number and all is
well. If we decide for some reason not to change the class, then what we
could do is hack the iic driver to generate a special number for those
based on priority checking but that's dead ugly. For that purpose, we
can use the reserved bit combination of 0xc0 in the HW irq numbers (see
interrupts.h for the mapping of iic interrupts) and we'l have to invent
an encoding for OF (which should be possible, we have the "ext" bits for
that).

But my preference is definitely to just use a different class.

Ben.