SVR5

intr(D2)

intr -- process a device interrupt

Synopsis

   int prefixintr(void *idata);

Description

The driver's intr( ) entry point routine is called when its device has generated an interrupt, or when another device that shares the same interrupt line has generated an interrupt.

Arguments

idata: For hardware drivers, a pointer to the device-specific instance data as output by the CFG_ADD subfunction of the config(D2) entry point routine. See ``Device instance'' in HDK Technical Reference.

Return values

The intr( ) routine should return one of the following values to indicate the interrupt status:

ISTAT_ASSERTED: The device identified by idata has asserted an interrupt.
ISTAT_ASSUMED: The driver cannot tell whether or not its device asserted an interrupt so is assuming that it did.
ISTAT_NONE: The device identified by idata did not assert an interrupt.

Usage

This entry point is only required for drivers that interface to hardware that interrupts the host computer. It is not used with software-only drivers or with drivers for devices that do not generate interrupts.

The interrupt handler is responsible for determining the reason for an interrupt, servicing the interrupt, and waking up any threads that are blocked waiting for an event associated with the interrupt.

For example, when a disk drive has transferred information to the host to satisfy a read request, the disk drive's controller generates an interrupt. The CPU acknowledges the interrupt and calls the interrupt handler associated with that controller and disk drive. The interrupt routine services the interrupt and then signals completion of the I/O with the biodone(D3) function, which unblocks any threads that are blocked with the biowait(D3) function, waiting on this request. The base-level portion of the driver then conveys the data to the user.

In general, most interrupt routines do the following tasks:

keep a record of interrupt occurrences
return immediately if no devices controlled by a driver caused the interrupt (only for systems supporting shared interrupts)
handle all possible device errors
wake threads that are blocked waiting for events associated with the interrupt

There are also many tasks the intr routine must perform that are driver-type and device specific. For example, the following types of drivers require different functions from their intr routines:

A terminal driver receives and sends characters.
A printer driver ensures that characters are sent.

In addition, the functions of an intr routine are device dependent. You should know the exact chip set that produces the interrupt for your device. You need to know the exact bit patterns of the device's control and status register and how data is transmitted into and out of your computer. These specifics differ for every device you access.

The intr routine for an adapter that does not use individual interrupt vectors for each subdevice must access the adapter's status to determine which subdevice generated the interrupt. It must also update the status information, set/clear flags, set/clear error indicators, and so forth to complete the handling of a job. The code should also be able to handle a spurious completion interrupt identified by an empty completion queue. When the routine finishes, it should advance the unload pointer to the next entry in the completion queue.

If the driver blocked with a syncronization primitive in HDK Technical Reference to await the completion of an operation, the intr( ) routine must call an appropriate function to signal the process to resume:

If blocked with SV_WAIT(D3) or SV_WAIT_SIG(D3), unblock with SV_SIGNAL(D3) or SV_BROADCAST(D3).
If blocked with biowait(D3), unblock with biodone(D3)
If blocked with sleep(D3), unblock with wakeup(D3).

The interrupt routine runs at the interrupt priority level (IPL) in HDK Technical Reference that is associated with the interrupt level for the given device. Lower priority interrupts are deferred while the interrupt routine is active. See spl(D3) for more information.

Context and synchronization

Interrupt context. The driver may not block or access any process state information.

The intr routine must never drop the interrupt priority level below the level at which the interrupt routine was entered or call the uiomove(D3), ureadc(D3), or uwritec(D3) functions when the uio_segflg member of the uio(D4) structure is set to UIO_USERSPACE (indicating a transfer between user and kernel space).

Hardware applicability

All

Version applicability

ddi: 1, 2, 3, 4, 5, 5mp, 6, 6mp, 7, 7mp, 7.1, 7.1mp, 8, 8mp

Differences between versions

In DDI versions prior to version 8, the syntax of the intr( ) routine is:

   void prefixintr(int ivec);

ivec is a number used by the operating system to associate a driver's interrupt handler with an interrupting device. The makeup and interpretation of ivec is specific to each system implementation. On some systems, this number may be the logical device number, or a combination of logical device and logical controller numbers, used to map the correct interrupt routine with a subdevice. On others, this number could be the interrupt vector number.

For non-loadable or non-autoconfigured DDI versions prior to version 8 that use the mod_drvattach(D3) function to attach interrupts, intr( ) is a named entry point and must be defined as a global symbol with the $entry intr string in the driver's Master(DSP/4dsp) file.

External dependencies

Named entry point routines must be declared in the driver's Master(DSP/4dsp) file. The declaration for this entry point is $entry intr. This applies only to non-STREAMS drivers that use DDI versions prior to version 8.

References

biodone(D3), biowait(D3), spl(D3), SV_BROADCAST(D3), SV_SIGNAL(D3), SV_WAIT(D3), SV_WAIT_SIG(D3), wakeup(D3)

intr(D2mdi), intr(D2sdi)

``Interrupts'' in HDK Technical Reference
``Interrupt handlers, attaching and registering'' in HDK Technical Reference