Messages in this thread | | | Subject | Re: MSI and driver APIs | From | Benjamin Herrenschmidt <> | Date | Fri, 16 Dec 2005 08:56:06 +1100 |
| |
> I think because of kinds of cases and other issues, going with > MSI by default is a non-starter. > > Perhaps a better approach is to use a flag in the pci_driver_struct or > similar that says "you can have MSI enabled by default". And > gradually convert drivers over which we know will handle it properly. > > Doing some tom foolery with request_irq() sounds like a half-baked > idea at best. The biggest argument against that is that this is > not a PCI interface, so expecting it to have PCI side effects is > really asking for trouble.
Hrm... true enough. I'll look into the driver flags option. I can probably always fallback to just turning MSI off everywhere at boot time and "reserve" an MSI number per device by simply holding on what was allocated by the firmware.
I was thinking that I might be able to not return the firmware allocated MSIs to the firmware, but just disable MSI in the device config space myself and keep track that N MSIs are still associated with the device even if not currently used. However, the way the IBM architecture is worded, it's unclear if that will work, that is, it's unclear that if I don't actually disable the MSIs with a firmware call (and thus return them), the interrupt controller will accept the INTx, chances are that it won't in fact.
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/
| |