Download C - Oracle Documentation

6
mutex_enter(&xsp->high_mu);
/* use data access routines to read status */
status = ddi_getb(xsp->data_access_handle,
(uchar_t *)&xsp->regp->csr);
if (!(status & INTERRUPTING)) {
mutex_exit(&xsp->high_mu);
return (DDI_INTR_UNCLAIMED); /* dev not interrupting */
}
/*
* Inform the device that it is being serviced, and re-enable
* interrupts. The example assumes that writing to the
* CSR accomplishes this. The driver must ensure that this data
* access operation makes it to the device before the interrupt
* service routine returns. For example, using the data access
* functions to read the CSR, if it does not result in unwanted
* effects, can ensure this.
*/
ddi_putb(xsp->data_access_handle,(uchar_t *)&xsp->regp->csr,
CLEAR_INTERRUPT | ENABLE_INTERRUPTS);
temp = ddi_getb(xsp->data_access_handle,
(uchar_t *) &xsp->regp->csr);
perform any I/O related and synchronization processing
signal waiting threads (biodone(9F) or cv_signal(9F)
mutex_exit(&xsp->mu);
return (DDI_INTR_CLAIMED);
}
When the system detects an interrupt on a bus architecture that does not
support vectored hardware, it calls the driver interrupt handler function for
each device that could have issued the interrupt. The interrupt handler must
determine whether the device it handles issued an interrupt.
On architectures supporting vectored interrupts, this step is unnecessary, but
not harmful, and it enhances portability. The syntax and semantics of the
interrupt handling routine therefore can be the same for both vectored
interrupts and polling interrupts.
In the model presented here, the argument passed to xxintr() is a pointer to
the state structure for the device that may have issued the interrupt. This was
set up by passing a pointer to the state structure as the intr_handler_arg
argument to ddi_add_intr(9F) in attach(9E).
Interrupt Handlers
123