RE: interruption sequence

[Richard Walter <rwalter@corp.auspex.com>]

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.

> From ivan_batinic@3mts.com Wed Mar 22 05:24:03 2000
> 
> Hello Assato san,
> 
> I understand your question:
> 
> 	How does an interrupt get associated with a device?
> 
> The answer is as follows:
> 
> 1.	The software handles the interrupt:
> 2.	The interrupt handling software must ask the possible devices if
> they have an interrupt pending.
> 3.	If no device has an interrupt pending, then process an error or
> ignore the interrupt.
> 4.	Else handle the device's request
> 5.	Continue polling possible interrupting devices
> 
> Note:  If the interrupt is not properly programmed in the PCI configuration
> space, then it is possible to have an interrupt handling error (see #3
> above).
> 
> I hope this answers your question.
> 
> Best regards,
> 
> Ivan
> 
> 
> -----Original Message-----
> From: ASATO [mailto:masato@d1.nas.nec.co.jp]
> Sent: Wednesday, March 22, 2000 2:46 AM
> To: pci-sig@znyx.com
> Subject: interruption sequence
> 
> 
> Hi all
> 
> It is unsuitable for the contents. I have some question.
> 
> Although the CBE bus was decoded in order to terminate interruption of
> device using the interrupt acknowledge, naturally the interruption signal to
> other devices will also be inputted.
> 
> How has knowing that it is the interrupt acknowledge turned to itself come
> out of device?
> 
> Or, device had to decode such as an address or something?
> 
> Please give me some advices interruption sequence
> 
> ----------------------------------------
>  ASKA Electronic corporation
>    ASATO
>  mailto:aac54490@pop17.odn.ne.jp
> ----------------------------------------