Messages in this thread | | | Subject | Re: [PATCH 2/2] Initial generic hypertransport interrupt support. | From | Benjamin Herrenschmidt <> | Date | Tue, 11 Jul 2006 19:15:46 +1000 |
| |
> Examples? details? patches? > > Part of the problem with plain MSI is that you can't mask irqs at the > source, in a generic way.
This is an interesting point, because this shows precisely the different of approach between most HW PPC implementations vs what x86 does and what the current code does...
Our MSIs are always routed as just additional sources to an existing IRQ controller that will itself then handle things like masking, affinity, etc...
Thus, we don't need nor want any kind of generic MSI code setting up an irq_chip with enable/disable functions etc... Those should stay the ones from the system's main PIC, maybe a different version of them, but that's up to the system PIC to set that up.
That's one of the reason why I think we need to work the MSI arch side API such that the MSI "controller" is the one to setup the irq_desc. The "generic" mask/unmask/etc... using the MSI(X) config space can be provided as optional helpers but it should be under arch, or more specifically MSI controller control to pick up how to setup the irq_desc and its associated irq_chip.
Another one is the fact that we have multiple different MSI mecanisms on the same machines (like the Apple Quad G5 which have on one side an MSI "register" that devices write to and that triggers sources on the MPIC, and on the other side, HT interrupts which can be generated from MSIs by the broadcom HT<->PCIe bridge). Thus that msi_ops stucture I've seen around shall really be per PCI host bridge at the very least. One propsal I have, but I didn't have time to actually implement it, was to have the msi_ops pointer be a field in pci_bus that is inherited by default. That is, the arch can call pci_set_msi_ops() on a given bus and this will propagate to childs.
Anyway, as I said, I didn't have time to code that part. So it's mostly food for thoughts.
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |