From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas To: Jonathan Larmour Cc: Robin Farine , ecos-discuss@sources.redhat.com Subject: Re: [ECOS] sa11x0 spurious interrupts Date: Tue, 13 Feb 2001 10:13:00 -0000 Message-id: References: <3A89787B.5F929C47@redhat.com> X-SW-Source: 2001-02/msg00209.html 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.