DragonFly kernel List (threaded) for 2005-05
Re: mtd_cpl question
Matthew Dillon wrote:
:The reason I ask is that I have the bus_alloc_resource() side of MSI
:(message signaled interrupts) working and wanted to connect it to the
:rest of the interrupt code via bus_setup_intr(). Do you have any
:short/long term recommendations? Do you want help on any of the above?>
:Alternatively, how badly would things break if I went around the system
:and wrote the IDT entries directly assuming there would be no overlap in
:the IRQ/MSI ranges?
I would say that bus_setup_intr() should specifically request them
with a flag. In particular, since we can't support SPL's on those
the device drivers that use them should not require the use of SPLs.
This means the setup call has to pass an interrupt type of INTR_TYPE_MISC
(i.e. no cpl mask involved).
Right now that is just the EM driver (I am about to commit the EM work
along with some major polling work). I believe once I do this commit
today you will then be able to use that as a basis for further work,
either to work with the EM driver itself or to see what I did to convert
a driver that you have hardware for. A network driver, please, disk
drivers still require SPLBIO to work.
Ok, I will start with the em driver. Are you suggesting a network driver
because the network stack does not depend on the BGL (I think that's
what you meant above wrt SPL)?
Are MSI interrupts edge triggered or level triggered? There's more
work involved if they are edge triggered.
PCIe defines them to be edge, but I'd have to look at the base spec to
know what happens on PCI.
You should be able to write IDT entries within the bounds of the IDT
table, as long as they do not interfere with existing IDT entries for
slow and fast interrupt vectors. I'm presuming that you will use the
same API that the interrupt code uses to access those entries, right ?
I'd rather use the existing API unless there is something that prevents it.