Well, with respect to MSI, yes it could. Interrupt values are
still a Linux fabrication regardless on many platforms with
cascaded PICs.
> > In that case, the PCI
> > subsystem would only need to provide an interface to provide
> > the architecture/platform specific inbound MSI location. The PCI
> > subsystem would then find all MSI capable PCI devices, and assign
> > the appropriate number of unique messages and inbound MSI address
> > to each device via the speced PCI MSI interface. The PCI subsystem
> > would also be responsible for maintaining a correspondence between
> > virtual Linux interrupt values and MSI values.
> >
> > Software specific to the PCI MSI capable "Northbridge", will then
> > route general MSI interrupt events to some PCI subsystem helper
> > functions to verify which MSI has occurred and thus which Linux
> > virtual interrupt.
>
> That sounds like a lot of overhead. In particular it means we keep
> converting to and from `virtual IRQs'. I would hope the MSI work would
> allow us to tie in at a lower level than virtual interrupts. I was
> thinking an interface would look something like:
Yes, it's a bit. Just pointing out that one *could* do it that way,
not really that we *should* do it that way. I would personally
prefer to see native msi support. However, most of the functionality
I mentioned are things the PCI subsystem needs to do specific to
PCI MSI anyway.
> void *request_msi(struct device *dev,
> irqreturn_t (*handler)(int, void *, struct pt_regs *),
> unsigned long irqflags,
> void *dev_id)
>
> You need a struct device to figure out which interrupt controller it
> needs.
request_msi() needs an additional parameter to specify which MSI
it is hooking. A device can implement many messages in order to
clarify which one of many events on a device has occurred. It
may be desired to hook a separate handler for each of those to
avoid another read of a status register.
Regards,
-- Matt Porter mporter@kernel.crashing.org - 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/