[ECOS] AT91: interrupt0 (fiq) and interrupt1 (swint) ?

[ECOS] AT91: interrupt0 (fiq) and interrupt1 (swint) ?

[Andrea Michelotti]

Why in hal_platform_ints.h interrupts 0 and 1 are not treated?
What does the comment "Note: extra slots (0,1) to avoid messing with vector
translation" mean?

thanks

Andrea

------------------
Andrea Michelotti
ATMEL Rome


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: AT91: interrupt0 (fiq) and interrupt1 (swint) ?

[Andrew Lunn]

On Wed, Sep 15, 2004 at 10:37:06AM +0200, Andrea Michelotti wrote:
> Why in hal_platform_ints.h interrupts 0 and 1 are not treated?
> What does the comment "Note: extra slots (0,1) to avoid messing with vector
> translation" mean?

I think its avoiding subtracting two from the value in the IVR
register. The value of 0 you proposed probably makes sense. So you
need to add #define CYGNUM_HAL_INTERRUPT_FIQ 0 and change
CYGNUM_HAL_ISR_MIN to 0.

        Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] AT91: interrupt0 (fiq) and interrupt1 (swint) ?

[Nick Garnett]

"Andrea Michelotti" <amichelotti@atmel.com> writes:

> Why in hal_platform_ints.h interrupts 0 and 1 are not treated?
> What does the comment "Note: extra slots (0,1) to avoid messing with vector
> translation" mean?

It means that the ISR table has 32 entries, but entries 0 and 1 are
unused. This allows vector numbers to translate directly to table
indexes. It simplifies the code at the expense of wasting some memory.

So, the table slot for your FIQ handler is present. I think all you
need to do is add a

#define CYGNUM_HAL_INTERRUPT_FIQ             0

somewhere and use that in your patch. It should probably go into
var_io.h since it is generic to all AT91s and is used in generic code.


However, in general eCos doesn't really support FIQs. The intended use
of FIQ is for very fast, low instruction count, interrupts -- software
DMA engines was the typical example. So the expected mechanism for
using FIQ is for the application to replace the FIQ VSR table entry
with a pointer to a short assembler routine. The FIQ support in the
HAL was mainly intended to support devices where the hardware
designers have connected a normal device to the FIQ for no good
reason, and to be able to catch and report spurious FIQs if they
occur.

For this reason, I think that the FIQ support in hal_IRQ_handler()
ought to be optional, and controlled by a config option. Otherwise all
platforms will pay the extra cost of testing for a FIQ when there is
never any possibility of the interrupt occuring.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] AT91: interrupt0 (fiq) and interrupt1 (swint) ?

[Andrea Michelotti]

I agree with you that maybe will be better to add some CDL entry to enable
FIQ handling in hal_IRQ_handler.
I think there is an extra cost in testing spurious interrupts too, because
in case of spurious interrupt ISR=0.
I try to do these patches and send you back.
best regards
Andrea.


> It means that the ISR table has 32 entries, but entries 0 and 1 are
> unused. This allows vector numbers to translate directly to table
> indexes. It simplifies the code at the expense of wasting some memory.
>
> So, the table slot for your FIQ handler is present. I think all you
> need to do is add a
>
> #define CYGNUM_HAL_INTERRUPT_FIQ             0
>
> somewhere and use that in your patch. It should probably go into
> var_io.h since it is generic to all AT91s and is used in generic code.
>
>
> However, in general eCos doesn't really support FIQs. The intended use
> of FIQ is for very fast, low instruction count, interrupts -- software
> DMA engines was the typical example. So the expected mechanism for
> using FIQ is for the application to replace the FIQ VSR table entry
> with a pointer to a short assembler routine. The FIQ support in the
> HAL was mainly intended to support devices where the hardware
> designers have connected a normal device to the FIQ for no good
> reason, and to be able to catch and report spurious FIQs if they
> occur.
>
> For this reason, I think that the FIQ support in hal_IRQ_handler()
> ought to be optional, and controlled by a config option. Otherwise all
> platforms will pay the extra cost of testing for a FIQ when there is
> never any possibility of the interrupt occuring.
>
>
> -- 
> Nick Garnett                    eCos Kernel Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss