Re: [ECOS] sa11x0 spurious interrupts

[Gary Thomas <gthomas at cambridge dot redhat dot com>]

On 13-Feb-2001 Jonathan Larmour wrote:
> Gary Thomas wrote:
>> 
>> 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.
> 
> Oops, I read too much into the name hal_IRQ_handler.
>  
>> > 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.
> 
> Yes I noticed on the AEB that it returns 13!
>  
>> These should all be changed to return CYGNUM_HAL_INTERRUPT_NONE
> 
> where CYGNUM_HAL_INTERRUPT_NONE is defined on every platform to be -1 I
> presume.
> 

Not necessarily.  The code in 'vectors.S' should just check for this [named] value.

>> 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 :-)
> 
> It depends on how spurious is spurious :).
> 
> Robin would you care to have a go at fixing this for all the
> hal_IRQ_handlers, i.e. in the aeb, pid, cma230, ebsa285, edb7xxx, and
> sa11x0/var dirs? As well as vector.S of course. ChangeLog entries would be
> superb :-).

If not, I can take care of it as well.