[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: interruption sequence



Hi, All
  I have asked this question before, but it seemed no one 
response to it.  Does any one who is familiar with WindowsNT 
PCI device driver  can give an explanation?

The original letter is as bellows:

  I have also another question. How does the Operation 
System process the PCI interrupt? For example, in WindowsNT, 
if you use DDK to develop a PCI device driver, it seemed 
that windowsNT knows which PCI device has generated the 
interrupt. so when you write the interrupt handler of a 
PCI device. All the things you should do is just filling  
some codes in the function. I am not quite sure about this, 
but if it's true, then different PCI device drivers are 
all independent. It is unnecessary to check the interrupt 
source in the device driver since OS has find it out, but 
how? could someone give me more detailed information?


> ----------
> From: 	Richard Walter[SMTP:rwalter@corp.auspex.com]
> Sent: 	Thursday, March 23, 2000 1:49 AM
> To: 	masato@d1.nas.nec.co.jp; pci-sig@znyx.com
> Subject: 	RE: interruption sequence
> 
>  
> Folks,
> 
> In addition to Ivan's answer (which I agree is correct), there is
> one other point that I think the original question was asking about:
> 
> In general, PCI devices should IGNORE the interrupt acknowledge bus
> cycle.  Interrupt Acknowledge is implicitly addressing the system
> interrupt
> controller, which 99.9% of the time is embedded in the chipset.  All
> other PCI devices should ignore it.  (To a certain extent, the INTACK
> is a case where x86 intrudes on the "architecture-independent" PCI bus.)
> 
> Ivan's answer listed the software steps of interrupt servicing.
> From a hardware perspective, this is what happens:
> (Items in ()'s happen without your device being aware of them.)
> 
> 1. Your device asserts INTx#.
> (2. The system interrupt controller notices that your INTx# is asserted
> 	and interrupts the CPU.)
> (3. The CPU issues a bus cycle to get the vector of the interrupt,
> 	generating an INTACK cycle on the PCI bus.)
> (4. The system interrupt controller responds to the INTACK cycle and
> 	returns vector information to the CPU.  (All other PCI devices
> 	ignore the INTACK cycle.) )
> (5. Software executes the interrupt service routine which needs to check
> 	all devices that are potentially sharing this interrupt to see
> 	who wants service.)
> 6. Your driver will read a bit from your device that indicates that it
> 	is asserting INTx#.  This bit can be located anywhere in your
> 	device's space; there is no PCI mandated location of this.
> 	(although it ought to be in a memory BAR and not config space.)
> 7. Your driver will service your device and then write control info back
> 	to the device indicating that it has serviced the interrupt.
> 8. Your device deasserts INTx#.
> 
> -Richard Walter
> rwalter@corp.auspex.com
> Note: I speak for myself, not for Auspex.