This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: interrupt handlers for the ARM SA1110



On 18-Jul-2001 Warren Jasper wrote:
> 
> This is a directed to Gary Thomas, but any comments are welcome.
> 

Why me?

> I have ported eCos to a development board with a BOPS's DSP and the
> Intel SA1110.  The DSP has it's own interrupt controller (with 32
> vectors or causes), so I would like to "cascade" that onto the current
> port.  I am using GPIO6 and GPIO7 as interrupts from the DSP's
> controller (ie, when the DSP's interrupt controller is configured
> properly, GPIO6 will go high on a DSP interrupt).
> 
> My question is where or how is the best way to do this?  I looked in
> sa11X0/var/current/src/sa11X0_misc.c as see some of the hooks, but am
> unsure how to either override or append to that.  I need to set up a
> secondary level of interrupts, which I would like to do in the HAL,
> and not in the application code.  Where is the best place to append
> more vectors?  If the name of my board is travis, do I have a
> sa11x0/travis/current/plf_intr.h or hal_intr.h?  How does that
> interface or override the one in sa11x0/var/current/{include,src} ?
> 

This would be in hal/arm/sa11x0/travis/current/hal_platform_ints.h
(yes, these files are not terribly consistent)  You can add the additional
interrupts from the DSP beyond the normal interrupts.  

As for your cascaded interrupt, all of this support can be handled in
your platform code (look at hal/arm/sa11x0/ipaq/current/src/ipaq_misc.c
for some examples).  

Handling the actual interrupt vectors for your additional sources would
involve some changes to the common (/var) code.  This can be added 
without too much perturbation, something like this:


void hal_interrupt_unmask(int vector)
{
#ifdef HAL_EXTENDED_INTERRUPT_UNMASK
    HAL_EXTENDED_INTERRUPT_UNMASK(vector)
#endif
    if (vector >= CYGNUM_HAL_INTERRUPT_GPIO11) {
        vector = CYGNUM_HAL_INTERRUPT_GPIO;
    }
    *SA11X0_ICMR |= (1 << vector);
}

Where (in your platform interrupt file) you'd define 

#define HAL_EXTENDED_INTERRUPT_UNMASK
    if (vector >= CYGNUM_HAL_INTERRUPT_DSP0) {
       // Do whatever is required
       return;
    }

Hopefully you get the picture.  Such additions to the common code would
be accepted back into the mainline by us and you'd have the support you
need.

> I would rather not have to modify the var files so my cvs tree remains
> consistant.
> 
> Where is the isr_springboard table like in the mips vrc4373 port?  I have ported
> the BOPS's DSP to another board running the QED rm5231 MIPS CPU, so I thought
> I was familiar with the basic eCos model for the HAL.
> 

The notion of 'isr_springboard' is unique to the MIPS.  Other processors
have different ways of handling low level interrupt vectoring code, thus
the setup is different.

> Also, what is the difference between say hal_interrupt_mask and
> HAL_INTERRUPT_MASK other than the obvious that one is a function and
> the other a macro.  Which one over-rides the other and where.

The HAL requires the macro(s), but the implementation of these functions
on the ARM are via functions, such as hal_interrupt_mask().


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]