The Xilinx interrupt controller driver component. This component supports the Xilinx interrupt controller.<p>
The interrupt controller driver uses the idea of priority for the various handlers. Priority is an integer within the range of 0 and 31 inclusive with 0 being the highest priority interrupt source.<p>
The Xilinx interrupt controller supports the following features:<p>
<li>specific individual interrupt enabling/disabling</li><li>specific individual interrupt acknowledging</li><li>attaching specific callback function to handle interrupt source</li><li>master enable/disable</li><li>single callback per interrupt or all pending interrupts handled for each interrupt of the processor</li></ul>
<p>
The acknowledgement of the interrupt within the interrupt controller is selectable, either prior to the device's handler being called or after the handler is called. This is necessary to support interrupt signal inputs which are either edge or level signals. Edge driven interrupt signals require that the interrupt is acknowledged prior to the interrupt being serviced in order to prevent the loss of interrupts which are occurring extremely close together. A level driven interrupt input signal requires the interrupt to acknowledged after servicing the interrupt to ensure that the interrupt only generates a single interrupt condition.<p>
Details about connecting the interrupt handler of the driver are contained in the source file specific to interrupt processing, <aclass="el"href="xintc__intr_8c.html">xintc_intr.c</a>.<p>
This driver is intended to be RTOS and processor independent. It works with physical addresses only. Any needs for dynamic memory management, threads or thread mutual exclusion, virtual memory, or cache control must be satisfied by the layer above this driver.<p>
<b>Interrupt Vector Tables</b><p>
The interrupt vector table for each interrupt controller device is declared statically in <aclass="el"href="xintc__g_8c.html">xintc_g.c</a> within the configuration data for each instance. The device ID of the interrupt controller device is used by the driver as a direct index into the configuration data table - to retrieve the vector table for an instance of the interrupt controller. The user should populate the vector table with handlers and callbacks at run-time using the <aclass="el"href="xintc_8c.html#ee9ec5873a764994d64b4da35a110084">XIntc_Connect()</a> and <aclass="el"href="xintc_8c.html#8f7caaeb26b6b264fffefbd32f90f855">XIntc_Disconnect()</a> functions.<p>
Each vector table entry corresponds to a device that can generate an interrupt. Each entry contains an interrupt handler function and an argument to be passed to the handler when an interrupt occurs. The tools default this argument to the base address of the interrupting device. Note that the device driver interrupt handlers given in this file do not take a base address as an argument, but instead take a pointer to the driver instance. This means that although the table is created statically, the user must still use <aclass="el"href="xintc_8c.html#ee9ec5873a764994d64b4da35a110084">XIntc_Connect()</a> when the interrupt handler takes an argument other than the base address. This is only to say that the existence of the static vector tables should not mislead the user into thinking they no longer need to register/connect interrupt handlers with this driver.<p>
