Re: [RFC/PATCH 6/7] MPIC MSI backend

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> > Yes, I will do a cleanup pass on the MPIC code there. I think it  
> > should
> > only program the chip for polarity/sense in startup() and thus can
> > "override" the native LSI setting of that vector when the interrupt is
> > flagged as MSI without actually losing the original information.
> 
> You mean when we (in the future) reserve a range of vectors
> for MSI allocation at MPIC startup?  Sure, that works.

Not only, even with the current code... basically keep the
sense/polarity flags of the LSI intact in the irq_desc, just add the
IRQF_MSI bit to "override" them when we configure the interrupt to be an
MSI. Then, irq_chip->startup() instead of set_irq_type() does the actual
configuration of the MPIC and, seeing the IRQF_MSI flags, does the right
thing.

That way, when restoring the IRQ back to LSI, we just clear IRQF_MSI and
the old sense/polarity settings will still be there in the descriptor
and MPIC will do the right thing on the next startup().

> ["The PCIe slot" == the 16x PCIe slot on PowerMacs here, for
> the record; it isn't connected over a bridge to HT, but is
> directly connected to the CPC945 (U4) chip.]

Yup, the Attu if you prefer :-)

> There are more problems there (with this current code): the LSI
> IRQ will always be #3, which cannot be used as an MSI IRQ;

Are you sure about that ? In this case, we need a special kludge for
now. I though the MSI stuff could override any of the MPIC vectors, but
you might well be right there, it might not work with the U4 internal
ones.

> and the MSI address to use can not be found on a parent HT bridge
> (as there is none, duh).  That last problem makes the patch
> perfectly safe for the CPC945 PCIe port though :-)

Yes, I know :-) We need specific code to discover that a device is
hanging off the Attu instead of HT. I already explained it all to
Michael, it shouldn't be too hard. I even have a card setup to test it,
just didn't have time to do it just yet.

> Can't we just check here?  If not, what's the point of having
> a return code here?  although doing the check in check() might
> be conceptually nicer, sure.

Yes, nicer and avoids going all the way to allocating stuff and then
having to de-allocate.

Ben.