1.\" Copyright (c) 2000 Jeroen Ruigrok van der Werven 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 13.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 14.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 15.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 16.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 17.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 18.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 19.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 20.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 21.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 22.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 23.\" SUCH DAMAGE. 24.\" 25.\" $FreeBSD$ 26.\" 27.Dd December 18, 2007 28.Dt BUS_SETUP_INTR 9 29.Os 30.Sh NAME 31.Nm BUS_SETUP_INTR , 32.Nm bus_setup_intr , 33.Nm BUS_TEARDOWN_INTR , 34.Nm bus_teardown_intr 35.Nd create, attach and teardown an interrupt handler 36.Sh SYNOPSIS 37.In sys/param.h 38.In sys/bus.h 39.Ft int 40.Fo BUS_SETUP_INTR 41.Fa "device_t dev" "device_t child" "struct resource *irq" "int flags" 42.Fa "driver_filter_t *filter" "driver_intr_t *ithread" "void *arg" 43.Fa "void **cookiep" 44.Fc 45.Ft int 46.Fo bus_setup_intr 47.Fa "device_t dev" "struct resource *r" "int flags" 48.Fa "driver_filter_t filter" "driver_intr_t ithread" "void *arg" 49.Fa "void **cookiep" 50.Fc 51.Ft int 52.Fo BUS_TEARDOWN_INTR 53.Fa "device_t dev" "device_t child" "struct resource *irq" "void *cookiep" 54.Fc 55.Ft int 56.Fn bus_teardown_intr "device_t dev" "struct resource *r" "void *cookiep" 57.Sh DESCRIPTION 58The 59.Fn BUS_SETUP_INTR 60method 61will create and attach an interrupt handler to an interrupt 62previously allocated by the resource manager's 63.Xr BUS_ALLOC_RESOURCE 9 64method. 65The 66.Fa flags 67are found in 68.In sys/bus.h , 69and give the broad category of interrupt. 70The 71.Fa flags 72also tell the interrupt handlers about certain 73device driver characteristics. 74.Dv INTR_EXCL 75marks the handler as being 76an exclusive handler for this interrupt. 77.Dv INTR_MPSAFE 78tells the scheduler that the interrupt handler 79is well behaved in a preemptive environment 80(``SMP safe''), 81and does not need 82to be protected by the ``Giant Lock'' mutex. 83.Dv INTR_ENTROPY 84marks the interrupt as being a good source of entropy - 85this may be used by the entropy device 86.Pa /dev/random . 87.Pp 88To define a time-critical handler (previously known as 89.Dv INTR_FAST ) 90that will not execute any potentially blocking operation, use the 91.Fa filter 92argument. 93See the 94.Sx "Filter Routines" 95section below for information on writing a filter. 96Otherwise, use the 97.Fa ithread 98argument. 99The defined handler 100will be called with the value 101.Fa arg 102as its only argument. 103See the 104.Sx "ithread Routines" 105section below for more information on writing an interrupt handler. 106.Pp 107The 108.Fa cookiep 109argument is a pointer to a 110.Vt "void *" 111that 112.Fn BUS_SETUP_INTR 113will write a cookie for the parent bus' use to if it is successful in 114establishing an interrupt. 115Driver writers may assume that this cookie will be non-zero. 116The nexus driver will write 0 on failure to 117.Fa cookiep . 118.Pp 119The interrupt handler will be detached by 120.Fn BUS_TEARDOWN_INTR . 121The cookie needs to be passed to 122.Fn BUS_TEARDOWN_INTR 123in order to tear down the correct interrupt handler. 124Once 125.Fn BUS_TEARDOWN_INTR 126returns, it is guaranteed that the interrupt function is not active and 127will no longer be called. 128.Pp 129Mutexes are not allowed to be held across calls to these functions. 130.Ss "Filter Routines" 131A filter runs in a context very similar to what was known as an 132.Dv INTR_FAST 133routine in previous versions of 134.Fx . 135In this context, normal mutexes cannot be used. 136Only the spin lock version of these can be used (specified by passing 137.Dv MTX_SPIN 138to 139.Fn mtx_init 140when initializing the mutex). 141.Xr wakeup 9 142and similar routines can be called. 143Atomic operations from 144.Pa machine/atomic 145may be used. 146Reads and writes to hardware through 147.Xr bus_space 9 148may be used. 149PCI configuration registers may be read and written. 150All other kernel interfaces cannot be used. 151.Pp 152In this restricted environment, care must be taken to account for all 153races. 154A careful analysis of races should be done as well. 155It is generally cheaper to take an extra interrupt, for example, than 156to protect variables with spinlocks. 157Read, modify, write cycles of hardware registers need to be carefully 158analyzed if other threads are accessing the same registers. 159.Pp 160Generally, a filter routine will use one of two strategies. 161The first strategy is to simply mask the interrupt in hardware and 162allow the 163.Dv ithread 164routine to read the state from the hardware and then reenable 165interrupts. 166The 167.Dv ithread 168also acknowledges the interrupt before re-enabling the interrupt 169source in hardware. 170Most PCI hardware can mask its interrupt source. 171.Pp 172The second common approach is to use a filter with multiple 173.Xr taskqueue 9 174tasks. 175In this case, the filter acknowledges the interrupts and queues the 176work to the appropriate taskqueue. 177Where one has to multiplex different kinds of interrupt sources, like 178a network card's transmit and receive paths, this can reduce lock 179contention and increase performance. 180.Pp 181You should not 182.Xr malloc 9 183from inside a filter. 184You may not call anything that uses a normal mutex. 185Witness may complain about these. 186.Ss "ithread Routines" 187You can do whatever you want in an ithread routine, except sleep. 188Care must be taken not to sleep in an ithread. 189In addition, one should minimize lock contention in an ithread routine 190because contested locks ripple over to all other ithread routines on 191that interrupt. 192.Ss "Sleeping" 193Sleeping is voluntarily giving up control of your thread. 194All the sleep routine found in 195.Xr msleep 9 196sleep. 197Waiting for a condition variable described in 198.Xr condvar 9 199is sleeping. 200Calling any function that does any of these things is sleeping. 201.Sh RETURN VALUES 202Zero is returned on success, 203otherwise an appropriate error is returned. 204.Sh SEE ALSO 205.Xr random 4 , 206.Xr device 9 , 207.Xr driver 9 , 208.Xr mtx_init 9 , 209.Xr wakeup 9 210.Sh AUTHORS 211.An -nosplit 212This manual page was written by 213.An Jeroen Ruigrok van der Werven 214.Aq asmodai@FreeBSD.org 215based on the manual pages for 216.Fn BUS_CREATE_INTR 217and 218.Fn BUS_CONNECT_INTR 219written by 220.An Doug Rabson 221.Aq dfr@FreeBSD.org . 222