This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: sa11x0 spurious interrupts
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: [ECOS] sa11x0 spurious interrupts
- From: Gary Thomas <gthomas at cambridge dot redhat dot com>
- Date: Tue, 13 Feb 2001 10:56:35 -0700 (MST)
- Cc: ecos-discuss at sources dot redhat dot com,Robin Farine <acnrf at dial dot eunet dot ch>
- Organization: Red Hat, Inc.
On 13-Feb-2001 Jonathan Larmour wrote:
> Robin Farine wrote:
>>
>> Hello,
>>
>> While looking at the way the sa11x0 hal's routine 'hal_IRQ_handler()' decodes
>> interrupt sources, I noticed that when it does not find an interrupt source,
>> the routine returns CYGNUM_HAL_INTERRUPT_NONE, which equals to -1 for this
>> platform. However, the common ARM code in "vectors.S" assumes that a spurious
>> interrupt always have the vector #0. And worse, 'handle_IRQ_or_FIQ' will call
>> 'hal_interrupt_handlers[-1]' which contains 0 and thus reboot!
>>
>> Did I miss something?
>
> I don't think so. 0 can be a valid ISR. What's worse is that the default
> ISR in hal/common also returns 0 to indicate a spurious interrupt.
The default ISR handler returning 0 is a whole separate matter.
>
> Anyone got any opinions why this isn't simply all wrong?
Actually, it does seem to be rather messed up. It comes from having a large
number of ports and this particular behaviour is platform specific, thus
we've somehow ended up with no less than 3 different answers here.
These should all be changed to return CYGNUM_HAL_INTERRUPT_NONE and have
the code in 'vectors.S' handle this as a special case. However, what one
actually does when there is a spurious interrupt is tinder for a large
flame war :-)