Lines Matching full:interrupt

9 ddi_trigger_softintr \- software interrupt handling routines
47 interrupt interfaces referenced in \fBIntro\fR(9F). Refer to \fIWriting Device
68 The type of soft interrupt to retrieve the cookie for.
77 Pointer to a location to store the interrupt block cookie.
98 A hint value describing the type of soft interrupt to generate.
107 Pointer to a soft interrupt identifier where a returned soft interrupt
117 Optional pointer to an interrupt block cookie where a returned interrupt block
127 Optional pointer to an interrupt device cookie where a returned interrupt
137 Pointer to interrupt handler.
146 Argument for interrupt handler.
158 The identifier specifying which soft interrupt handler to remove.
170 The identifier specifying which soft interrupt to trigger and which soft
171 interrupt handler will be called.
180 \fBddi_get_soft_iblock_cookie()\fR retrieves the interrupt block cookie
181 associated with a particular soft interrupt preference level. This routine
182 should be called before \fBddi_add_softintr()\fR to retrieve the interrupt
184 used by the software interrupt routine. \fIpreference\fR determines which type
185 of soft interrupt to retrieve the cookie for. The possible values for
193 Low priority soft interrupt.
202 Medium priority soft interrupt.
211 High priority soft interrupt.
217 initializing locks associated with this soft interrupt (see
219 mutexes acquired by the interrupt routine before calling
221 driver's soft interrupt handler is called immediately \fBafter\fR the driver
223 the mutexes. This can happen when a soft interrupt for a different device
224 occurs on the same soft interrupt priority level. If the soft interrupt routine
232 \fBddi_add_softintr()\fR adds a soft interrupt to the system. The user
234 system to attempt to allocate the soft interrupt priority at. The value for
241 interrupt identifier. This value is used in later calls to
243 soft interrupt and the soft interrupt handler.
247 interrupt block cookie which contains information used for initializing mutexes
248 associated with this soft interrupt (see \fBmutex_init\fR(9F) and
249 \fBrw_init\fR(9F)). Note that the interrupt block cookie is normally obtained
260 called upon receipt of a software interrupt. Software interrupt handlers must
262 interrupt handlers) they may run because a soft interrupt occurred for some
263 other reason. For example, another driver may have triggered a soft interrupt
264 at the same level. For this reason, before triggering the soft interrupt, the
265 driver must indicate to its soft interrupt handler that it should do work. This
268 determine if it should claim the interrupt and do its work.
271 The interrupt handler must return \fBDDI_INTR_CLAIMED\fR if the interrupt was
276 interrupt information cannot be found, it will return \fBDDI_FAILURE\fR.
282 \fBddi_remove_softintr()\fR removes a soft interrupt from the system. The soft
283 interrupt identifier \fIid\fR, which was returned from a call to
284 \fBddi_add_softintr()\fR, is used to determine which soft interrupt and which
285 soft interrupt handler to remove. Drivers must remove any soft interrupt
292 \fBddi_trigger_softintr()\fR triggers a soft interrupt. The soft interrupt
293 identifier \fIid\fR is used to determine which soft interrupt to trigger. This
294 function is used by device drivers when they wish to trigger a soft interrupt
322 \fBddi_trigger_softintr()\fR may be called from high-level interrupt context as
330 interrupts are those that interrupt at the level of the scheduler and above.
333 by the scheduler. In addition, high level interrupt handlers must take care to
339 In the example, the high-level interrupt routine minimally services the device,
340 and enqueues the data for later processing by the soft interrupt handler. If
341 the soft interrupt handler is not currently running, the high-level interrupt
342 routine triggers a soft interrupt so the soft interrupt handler can process the
343 data. Once running, the soft interrupt handler processes all the enqueued data
349 protect data shared between the high-level interrupt handler and the soft
350 interrupt handler. The low-level mutex is used to protect the rest of the
351 driver from the soft interrupt handler.
379 interrupt handler and \fBddi_add_softintr()\fR is used to add the low-level
380 interrupt routine.
432 \fBExample 3 \fRHigh-level interrupt routine
435 The next code fragment represents the high-level interrupt routine. The
436 high-level interrupt routine minimally services the device, and enqueues the
437 data for later processing by the soft interrupt routine. If the soft interrupt
439 the routine. The soft interrupt routine will run until there is no more data on
453          * Verify this device generated the interrupt
454          * and disable the device interrupt.
537 \fBddi_add_softintr()\fR may not be used to add the same software interrupt
540 Instead, the argument passed to the interrupt handler should indicate what
541 service(s) the interrupt handler should perform. For example, the argument