Interrupt Handling in Test Units

A typical sequence of events in the functional flow of a Test Unit is to set up a device operation through reads and writes to the device address space, and then wait to receive an interrupt from the device to indicate that an operation has completed or needs attention. Since interrupt handling is device-specific and part of the test process, an interrupt handler function must be provided in addition to the Test Unit library. When a device is opened for testing by Test Unit 1 (TU_OPEN), an interrupt handler may be loaded (if one is needed) by passing an interrupt handler module name as one of the parameters on the pdiag_open system service. A data buffer address is also passed as part of the input to the pdiag_open function, so the device methods know which interrupt handler to use, as well as where to pass back data from the interrupt handler.

The purpose of the interrupt handler function is to receive the interrupt indication, possibly gather some information from the device, clear the interrupt condition on the device, and notify a waiting Test Unit that the interrupt has occurred. Clearing of the interrupt condition is critical, because the interrupt handler will be called continuously as long as the interrupt condition exists. Since this function is called to handle a specific device I/O interrupt, the information it gathers from the device is useful in diagnosing the device behavior. The interrupt handler puts this information into the data buffer area (defined at device-open time), where the waiting Test Unit can access it for analysis.

The basic flow of interrupt processing is shown in the "Interrupt Processing in Test Units" illustration. The flow of events is as follows:

1. An exectu() call is made to Test Unit 1 (TU_OPEN), which calls pdiag_open to open the device for testing. Included in the input information passed to pdiag_open is the name of the interrupt handler module and the address of a memory-allocated data buffer area.
2. A Test Unit is started, which performs some operations on the device, and then calls pdiag_dd_watch_for_interrupt to wait for a response in the form of a device interrupt (or a time-out if no interrupt occurs).
3. The device-methods layer receives an interrupt indication from the operating system.
4. The device-methods pass control to the registered interrupt handler.
5. The interrupt handler function gathers data from the device and places it in the data buffer area, clears the interrupt, and releases the Test Unit from its WAIT state.
6. The interrupt handler completes and returns to the caller (the device methods).
7. The Test Unit continues execution by processing the data returned from the interrupt handler.
8. When testing is completed, a call is made to Test Unit 0xEFFF (TU_CLOSE), which calls pdiag_close to close the device and unload the interrupt handler.

The cycle of device setup and wait for interrupt can be repeated as often as necessary during the execution of the Test Units. Registration of the interrupt handler only needs to be done once, at the time when the device is opened for testing. However, different interrupt handlers could be used (if necessary) by closing the device, then reopening the device with a different interrupt handler module-name parameter.