This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: AT91 bad IRQ/FIQ priority handling?
The code I added is related only to the FIQ interrupt source generally
linked to the line 0 of the AIC (atmel Advanced Interrupt Controller) .
In fact if the FIQ line is linked to another line (possible, but, as far as
I know, in atmel AIC fiq line is for default to 0) this code is not correct
but should be modified introducing a constant that identify the FIQ line.
Does hal_platform_ints.h have a macro to identify FIQ interrupt sources?
If not, I propose to add one to handle this kind of situations in at91
targets.
what do you think?
thanks
Andrea.
> On Tue, Sep 14, 2004 at 11:48:05AM +0200, Andrea Michelotti wrote:
> > int hal_IRQ_handler(void)
> > {
> > cyg_uint32 irq_num;
> >- cyg_uint32 ivr;
> >+ cyg_uint32 ivr,ipr,imr;
> >+ HAL_READ_UINT32(AT91_AIC+AT91_AIC_IPR, ipr);
> >+ HAL_READ_UINT32(AT91_AIC+AT91_AIC_IMR, imr);
> >+
> >+ if(imr&ipr&0x1){
> >+ HAL_WRITE_UINT32(AT91_AIC+AT91_AIC_ICCR, 1); // we must clean
pending fiq
> >+ return 0;
> >+ }
> >
> > // Calculate active interrupt (updates ISR)
> > HAL_READ_UINT32(AT91_AIC+AT91_AIC_IVR, ivr);
> >
> > HAL_READ_UINT32(AT91_AIC+AT91_AIC_ISR, irq_num);
>
> Returning 0 is wrong. You need to return the interrupt source as
> defined in hal_platform_ints.h.
>
> 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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss