udi_intr_event_rdy(3udi)
Acknowledge an interrupt event
#include <udi.h>void udi_intr_event_rdy ( udi_intr_event_cb_t *intr_event_cb );ARGUMENTS intr_event_cb is a pointer to an interrupt event control block.
TARGET CHANNEL The target channel for this operation is the interrupt event channel for this attachment, jointly spawned by the interrupt handler and interrupt dispatcher during interrupt attachment (see udi_intr_attach_req, udi_intr_attach_ack). The interrupt dispatcher driver can use the channel context pointer for this channel to distinguish this response from responses for other attached interrupts.
DESCRIPTION An interrupt handler driver uses udi_intr_event_rdy to send an interrupt event control block to the dispatcher driver. These event control blocks allow the dispatcher to notify the handler of interrupt events, so the handler should endeavor to keep a number of these posted to the dispatcher to avoid missing interrupts. When the dispatcher indicates an interrupt, the handler should process the interrupt quickly and return the control block to the dispatcher to be used for future interrupt indications.
For a leaf interrupt source, this often means accessing some device-specific register which causes the device to stop asserting the interrupt. Leaf drivers must call udi_intr_event_rdy before returning from udi_intr_event_ind. Bridge drivers may complete the interrupt handling by passing the udi_intr_event_rdy on to their parent bridge, or may invoke another interrupt handler with udi_intr_event_ind.
For an interrupt handler which is also a dispatcher, udi_intr_event_rdy should be called immediately if the UDI_INTR_MASKING_NOT_REQUIRED flag is set, or after masking the interrupt if possible. If the interrupt could not be masked, then udi_intr_event_rdy should be called upon receipt of a udi_intr_event_rdy operation from the child handler driver.
In either case, if not using interrupt preprocessing, the handler driver must set intr_result in the control block to zero if its device asserted the interrupt (or the interrupt is non-sharable as indicated by the "nonsharable_interrupt" declaration) or to UDI_INTR_UNCLAIMED if the device was not the source of the interrupt. When using interrupt preprocessing, intr_result is ignored for udi_intr_event_ind.
The udi_intr_event_rdy operation must only be used when the handler is attached for that interrupt source (via udi_intr_attach_req).
The handler determines the number of interrupts indications that may be handled for this device by controlling the number of interrupt event control blocks that are used. The handler may allocate more interrupt control blocks at any time that it is attached to the interrupt dispatcher and provide those control blocks to the dispatcher for processing via the udi_intr_event_rdy operation; the intr_result field of these newly allocated control blocks should be set to UDI_INTR_NO_EVENT. If the handler wishes to reduce the number of interrupts being handled, it should reduce the number of interrupt control blocks available to the dispatcher by using udi_channel_op_abort and subsequently deallocating the aborted control blocks; the handler should not simply deallocate control blocks delivered via the udi_intr_event_ind operation since the interrupt must be acknowledged back to the dispatcher via the udi_intr_event_rdy operation.
warnings The control block must be the same control block as passed to the driver in the corresponding udi_intr_event_ind operation.
REFERENCES udi_intr_event_cb_t, udi_intr_attach_ack, udi_intr_event_ind, udi_channel_op_abort