1 .\" Copyright (c) 2000 Jeroen Ruigrok van der Werven
2 .\" All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
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.
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
33 .Nm BUS_TEARDOWN_INTR ,
35 .Nd create, attach and teardown an interrupt handler
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"
47 .Fa "device_t dev" "struct resource *r" "int flags"
48 .Fa "driver_filter_t filter" "driver_intr_t ithread" "void *arg"
53 .Fa "device_t dev" "device_t child" "struct resource *irq" "void *cookiep"
56 .Fn bus_teardown_intr "device_t dev" "struct resource *r" "void *cookiep"
61 will create and attach an interrupt handler to an interrupt
62 previously allocated by the resource manager's
63 .Xr BUS_ALLOC_RESOURCE 9
69 and give the broad category of interrupt.
72 also tell the interrupt handlers about certain
73 device driver characteristics.
75 marks the handler as being
76 an exclusive handler for this interrupt.
78 tells the scheduler that the interrupt handler
79 is well behaved in a preemptive environment
82 to be protected by the ``Giant Lock'' mutex.
84 marks the interrupt as being a good source of entropy -
85 this may be used by the entropy device
88 To define a time-critical handler that will not execute any potentially
89 blocking operation, use the
94 section below for information on writing a filter.
99 will be called with the value
101 as its only argument.
103 .Sx "ithread Routines"
104 section below for more information on writing an interrupt handler.
108 argument is a pointer to a
112 will write a cookie for the parent bus' use to if it is successful in
113 establishing an interrupt.
114 Driver writers may assume that this cookie will be non-zero.
115 The nexus driver will write 0 on failure to
118 The interrupt handler will be detached by
119 .Fn BUS_TEARDOWN_INTR .
120 The cookie needs to be passed to
121 .Fn BUS_TEARDOWN_INTR
122 in order to tear down the correct interrupt handler.
124 .Fn BUS_TEARDOWN_INTR
125 returns, it is guaranteed that the interrupt function is not active and
126 will no longer be called.
128 Mutexes are not allowed to be held across calls to these functions.
129 .Ss "Filter Routines"
130 A filter runs in primary interrupt context.
131 In this context, normal mutexes cannot be used.
132 Only the spin lock version of these can be used (specified by passing
136 when initializing the mutex).
138 and similar routines can be called.
139 Atomic operations from
142 Reads and writes to hardware through
145 PCI configuration registers may be read and written.
146 All other kernel interfaces cannot be used.
148 In this restricted environment, care must be taken to account for all
150 A careful analysis of races should be done as well.
151 It is generally cheaper to take an extra interrupt, for example, than
152 to protect variables with spinlocks.
153 Read, modify, write cycles of hardware registers need to be carefully
154 analyzed if other threads are accessing the same registers.
156 Generally, a filter routine will use one of two strategies.
157 The first strategy is to simply mask the interrupt in hardware and
160 routine to read the state from the hardware and then reenable
164 also acknowledges the interrupt before re-enabling the interrupt
166 Most PCI hardware can mask its interrupt source.
168 The second common approach is to use a filter with multiple
171 In this case, the filter acknowledges the interrupts and queues the
172 work to the appropriate taskqueue.
173 Where one has to multiplex different kinds of interrupt sources, like
174 a network card's transmit and receive paths, this can reduce lock
175 contention and increase performance.
179 from inside a filter.
180 You may not call anything that uses a normal mutex.
181 Witness may complain about these.
182 .Ss "ithread Routines"
183 You can do whatever you want in an ithread routine, except sleep.
184 Care must be taken not to sleep in an ithread.
185 In addition, one should minimize lock contention in an ithread routine
186 because contested locks ripple over to all other ithread routines on
189 Sleeping is voluntarily giving up control of your thread.
190 All the sleep routine found in
193 Waiting for a condition variable described in
196 Calling any function that does any of these things is sleeping.
198 Zero is returned on success,
199 otherwise an appropriate error is returned.
207 This manual page was written by
208 .An Jeroen Ruigrok van der Werven
209 .Aq asmodai@FreeBSD.org
210 based on the manual pages for
216 .Aq dfr@FreeBSD.org .