Next | Prev | Up | Top | Contents | Index
Allocating an Interrupt Vector Dynamically
When a VME device generates an interrupt, the Silicon Graphics VME controller initiates an interrupt acknowledge (IACK) cycle on the VME bus. During this cycle, the interrupting device presents a data value that characterizes the interrupt. This is the interrupt vector, in VME terminology.
According to the VME standard, the interrupt vector can be a data item of 8, 16, or 32 bits. However, Silicon Graphics systems accept only an 8-bit vector, and its value must fall in the range 1-254 inclusive. (0x00 and 0xFF are excluded because they could be generated by a hardware fault.)
The interrupt vector returned by some VME devices is hard-wired or configured into the board with switches or jumpers. When this is the case, the vector number should be written as the vector parameter in the VECTOR statement that describes the device (see "Configuring the System Files").
Some VME devices are programmed with a vector number at runtime. For these devices, you omit the vector parameter, or give its value as an asterisk. In the device driver, you use the functions in Table 14-3 to choose a vector number.
Functions to Manage Interrupt Vector Values
| Function | Header Files | Can Sleep | Purpose |
|---|
| vme_ivec_alloc(D3) | vmereg.h & types.h | N | Allocate a VME bus interrupt vector. |
| vme_ivec_free(D3) | vmereg.h & types.h | N | Free a VME bus interrupt vector. |
| vme_ivec_set(D3) | vmereg.h & types.h | N | Register a VME bus interrupt vector. |
Allocating a Vector
In the pfxedtinit() entry point, the device driver selects a vector number for the device to use. The best way to select a number is to call vme_ivec_alloc(), which returns a number that has not been registered for that bus, either dynamically or in a VECTOR line.
The driver then uses vme_ivec_set() to register the chosen vector number. This function takes parameters that specify
- The vector number
- The bus number to which it applies
- The address of the interrupt handler for this vector--typically but not necessarily the name of the pfxintr() entry point of the same driver
- An integer value to be passed to the interrupt entry point--typically but not necessarily the vector number
The vme_ivec_set() function simply registers the number in the kernel, with the following two effects:
- The vme_ivec_alloc() function does not return the same number to another call until the number is released.
- The specified handler is called when any device presents this vector number on an interrupt.
Multiple devices can present the identical vector, provided that the interrupt handler has some way of distinguishing one device from another.
Note: If you are working with both the VME and EISA interfaces, it is worth noting that the number and types of arguments of vme_ivec_set() differ from the similar EISA support function eisa_ivec_set().
Releasing a Vector
There is a limit of 254 vector numbers per bus, so it is a good idea for a loadable driver, in its pfxunload() entry point, to release a vector by calling vme_ivec_free() (see "Entry Point unload()" and "Unloading").
Vector Errors
A common problem with programmable vectors in the Challenge or Onyx systems is the appearance of the following warning in the SYSLOG file:
Warning: Stray VME interrupt: vector =0xff
One possible cause of this error is that the board is emitting the wrong interrupt vector; another is that the board is emitting the correct vector but with the wrong timing, so that the VME bus adapter samples all-binary-1 instead. Both these conditions can be verified with a VME bus analyzer. In the Challenge or Onyx hardware design, the most likely cause is the presence of empty slots in the VME card cage. All empty slots must be properly jumpered in order to pass interrupts correctly.
Next | Prev | Up | Top | Contents | Index