RE: interruption sequence

[Gérard Roudier <groudier@club-internet.fr>]

On Wed, 22 Mar 2000, Richard Walter wrote:

> 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.

Hmmm... point 7 may lead to the following race with PCI devices that
donnot stop while the CPU is handling IO completions.

> 7. Your driver will service your device

And a new IO completion is pushed to the CPU by the chip (generally by
some write to memory from the PCI BUS)

> and then write control info back
> 	to the device indicating that it has serviced the interrupt.

And interrupt may not occur later for the new IO that completed just prior
to the `write control info back' having been actually seen by the device.

Btw, there are several ways to handle things right, for example:
  
>From interrupt service routine:

  1) read some status bit that indicate device is asserting INTx.

  2) if not set, return
     otherwise clear some status bit that tells the PCI device that CPU 
     is about to handle completed IOs. Device will then deassert INTx.

  3) ensure the device is aware of this by flushing PCI posted writes  
     using a dummy read if needed (MMIO or host bridges that also post
     normal IOs)

  4) handles all IO completions. 

  5) return

There is no race here, since if new IOs complete and are missed by the
interrupt routine, INTx will be asserted again and the interrupt routine
will be reentered for these new completions.

Gérard.