Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 19 Oct 2000 18:13:24 -0500

Timo Korhonen wrote:
> 
> 1. The mv2306 structure permits having multiple handlers attached to the same
> vector. However, this causes problems for devDisconnectInterrupt (if the
> same routine is attached several times with different parameters, there is
> no way to tell which one to disconnect.)
> Allowing only one routine per vector (like in 68K) should be ok?

This is probably OK for VMEbus drivers, I suspect the linked list was used
to keep all interrupts being handled by the same type of structure. 
PCIbus interrupts don't have vectors and thus will need to be chained if
an IRQ line is shared by multiple devices.

For the mv2700 BSP here at APS I didn't want to substantially change the
way the BSP worked, so I've kept the chain.  There probably should be an
intDisconnect() routine to cope with situations like your driver, but I
wouldn't use the technique you described myself because this isn't a
standard vxWorks facility.  I would change the driver to connect just one
routine that makes a call through a global function pointer.  It can just
change the function pointer itself when it wants to switch to a different
service routine, so doesn't need anything like intDisconnect().

I added a routine to ravenMpic.c in our mv2700 BSP to be called by
intVecGet() and return the first entry in the chain for the given vector
number.  This removes the need to change veclist.c other than to exclude
the default handler stub tests.  My additions were as follows:

/* globals */
IMPORT FUNCPTR        (*_func_intVecGetRtn) (FUNCPTR *);
...
/* forward declarations */
LOCAL STATUS    sysMpicIntConnect (VOIDFUNCPTR * vector, VOIDFUNCPTR
routine,
                               int parameter);
...
STATUS sysMpicInit (void) {
...
    _func_intVecGetRtn = sysMpicIntVecGet;
...
}
...
/******************************************************************************
*
* sysMpicIntVecGet - get an interrupt vector
*
* This function returns a pointer to the interrupt handler attached to
* a specified vector offset.  On the PowerPC the vector offset is the
* same as the vector number, thus INUM_TO_IVEC is a null macro.
*
* RETURNS: A pointer to the first interrupt handler routine in the chain
* for the given vector number, or NULL if none connected or vector number
* out of range.
*/

LOCAL FUNCPTR sysMpicIntVecGet
    (
    FUNCPTR *  vector  /* vector offset */
    )
    {
    if (((int)vector < 0) || ((int)vector > 0xff))      /* Out of Range?
*/
        return (NULL);

    if (sysIntTbl[(int) vector] == NULL)
        return (NULL);

    return (FUNCPTR)(sysIntTbl[(int) vector]->vec);
    }

> 3. The list of unexpected interrupt handlers is not very relevant in the case of
> mv2306, because the Universe interrupt handler checks the vector table and
> complains if the interrupt handler entry is NULL.
> It is not necessary to have a handler attached to unused vectors. This is just
> cosmetics, but in the patches I remove the default vxWorks handler stub
> definitions from the table, to avoid confusing error messages during startup.

Agreed, the stubs are not useful for PowerPC, but 68K targets do need
them.  I would like to see veclist regard NULL returns from intVecGet() as
unconnected vectors on PPC, but keep the old functionality for the 68K
family.

> 4. I am not sure if this applies to other than mv2300 series ioc. Because of
> this, I used #ifdef MV2300 in the patches.

Something similar will apply to any PowerPC board, because there is only
one external interrupt line so vectors have to be looked up by software on
this architecture.  By implementing intVecGet() we remain as compatible as
possible between architectures.

- Andrew
-- 
Every great idea appears crazy to start with.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System