Jean-Baptiste Note wrote:
What are we talking about here anyway ? You need an acknowledgement of
the IRQ anyway, so there will be a write on the PCI. We're talking
about saving a couple microseconds for reading an IRQ status register
on PCI, this against alienating customers, having to delve into
low-level linux PCI code and generally having a headache about
debugging the stuff.
The OS code isn't something that customers need to worry about.
What are we talking about? The question is whether or not service of
the 'service' interrupt will introduce too much latency in the service
of the 'sync' interrupt.
What your 'analysis' fails to consider is that, if shared, that the
'sync' interrupt cannot be serviced until service of the 'service'
interrupt has completed to the point that the interrupt has been cleared
(in hardware) and interrupt is enabled. Also not considered is that
these two interrupts should have different priorities.
IAC, this doesn't make any difference unless the system the board is
plugged into has enough interrupt controller hardware to make a separate
hardware interrupt available for the 'sync' interrupt -- the 'service'
interrupt can be shared with other interrupts since it doesn't need the
high priority.
I also note (for example) that AGP cards have two interrupts, but many
systems share these. So, it only matters if the system has the hardware
interrupts available. But, if the two interrupts are not separate, then
the system must share them even if it has the hardware available to
provide separate interrupts. That is what I am talking about.
If multiple hardware interrupts weren't any advantage, they why do we
have multiple hardware interrupts -- why don't all I/O devices just
share one interrupt?
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
