NAME

     BUS_SETUP_INTR, bus_setup_intr, BUS_TEARDOWN_INTR, bus_teardown_intr — create, attach and
     teardown an interrupt handler

SYNOPSIS

     #include <sys/param.h>
     #include <sys/bus.h>

     int
     BUS_SETUP_INTR(device_t dev, device_t child, struct resource *irq, int flags,
         driver_filter_t *filter, driver_intr_t *ithread, void *arg, void **cookiep);

     int
     bus_setup_intr(device_t dev, struct resource *r, int flags, driver_filter_t filter,
         driver_intr_t ithread, void *arg, void **cookiep);

     int
     BUS_TEARDOWN_INTR(device_t dev, device_t child, struct resource *irq, void *cookiep);

     int
     bus_teardown_intr(device_t dev, struct resource *r, void *cookiep);

DESCRIPTION

     The BUS_SETUP_INTR() method will create and attach an interrupt handler to an interrupt
     previously allocated by the resource manager's BUS_ALLOC_RESOURCE(9) method.  The flags are
     found in <sys/bus.h>, and give the broad category of interrupt.  The flags also tell the
     interrupt handlers about certain device driver characteristics.  INTR_EXCL marks the handler
     as being an exclusive handler for this interrupt.  INTR_MPSAFE tells the scheduler that the
     interrupt handler is well behaved in a preemptive environment (``SMP safe''), and does not
     need to be protected by the ``Giant Lock'' mutex.  INTR_ENTROPY marks the interrupt as being
     a good source of entropy - this may be used by the entropy device /dev/random.

     To define a time-critical handler that will not execute any potentially blocking operation,
     use the filter argument.  See the Filter Routines section below for information on writing a
     filter.  Otherwise, use the ithread argument.  The defined handler will be called with the
     value arg as its only argument.  See the ithread Routines section below for more information
     on writing an interrupt handler.

     The cookiep argument is a pointer to a void * that BUS_SETUP_INTR() will write a cookie for
     the parent bus' use to if it is successful in establishing an interrupt.  Driver writers may
     assume that this cookie will be non-zero.  The nexus driver will write 0 on failure to
     cookiep.

     The interrupt handler will be detached by BUS_TEARDOWN_INTR().  The cookie needs to be
     passed to BUS_TEARDOWN_INTR() in order to tear down the correct interrupt handler.  Once
     BUS_TEARDOWN_INTR() returns, it is guaranteed that the interrupt function is not active and
     will no longer be called.

     Mutexes are not allowed to be held across calls to these functions.

   Filter Routines
     A filter runs in primary interrupt context.  In this context, normal mutexes cannot be used.
     Only the spin lock version of these can be used (specified by passing MTX_SPIN to mtx_init()
     when initializing the mutex).  wakeup(9) and similar routines can be called.  Atomic
     operations from machine/atomic may be used.  Reads and writes to hardware through
     bus_space(9) may be used.  PCI configuration registers may be read and written.  All other
     kernel interfaces cannot be used.

     In this restricted environment, care must be taken to account for all races.  A careful
     analysis of races should be done as well.  It is generally cheaper to take an extra
     interrupt, for example, than to protect variables with spinlocks.  Read, modify, write
     cycles of hardware registers need to be carefully analyzed if other threads are accessing
     the same registers.

     Generally, a filter routine will use one of two strategies.  The first strategy is to simply
     mask the interrupt in hardware and allow the ithread routine to read the state from the
     hardware and then reenable interrupts.  The ithread also acknowledges the interrupt before
     re-enabling the interrupt source in hardware.  Most PCI hardware can mask its interrupt
     source.

     The second common approach is to use a filter with multiple taskqueue(9) tasks.  In this
     case, the filter acknowledges the interrupts and queues the work to the appropriate
     taskqueue.  Where one has to multiplex different kinds of interrupt sources, like a network
     card's transmit and receive paths, this can reduce lock contention and increase performance.

     You should not malloc(9) from inside a filter.  You may not call anything that uses a normal
     mutex.  Witness may complain about these.

   ithread Routines
     You can do whatever you want in an ithread routine, except sleep.  Care must be taken not to
     sleep in an ithread.  In addition, one should minimize lock contention in an ithread routine
     because contested locks ripple over to all other ithread routines on that interrupt.

   Sleeping
     Sleeping is voluntarily giving up control of your thread.  All the sleep routine found in
     msleep(9) sleep.  Waiting for a condition variable described in condvar(9) is sleeping.
     Calling any function that does any of these things is sleeping.

RETURN VALUES

     Zero is returned on success, otherwise an appropriate error is returned.

SEE ALSO

     random(4), device(9), driver(9), locking(9)

AUTHORS

     This manual page was written by Jeroen Ruigrok van der Werven ⟨asmodai@FreeBSD.org⟩ based on
     the manual pages for BUS_CREATE_INTR() and BUS_CONNECT_INTR() written by Doug Rabson
     ⟨dfr@FreeBSD.org⟩.