From 23e59f20bf3651d1cf3dcedc08ddc10de9827f3d Mon Sep 17 00:00:00 2001 From: Michael Sevakis Date: Thu, 27 Nov 2008 11:49:49 +0000 Subject: Gigabeats S: Simply ignore that occasional spurious unknown IRQ (-1) that goes through irq_handler even if the AVIC is used. If no pending interrupt is indicated (anything else should be vectored), simply returning from the handler appears to have no ill effect. The cause for entering irq_handler is unknown for now (or I missed something important :\). git-svn-id: svn://svn.rockbox.org/rockbox/trunk@19245 a1c6a512-1295-4272-9138-f99709370657 --- firmware/target/arm/imx31/gigabeat-s/avic-imx31.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/firmware/target/arm/imx31/gigabeat-s/avic-imx31.c b/firmware/target/arm/imx31/gigabeat-s/avic-imx31.c index ba7ed3314c..a135889e6e 100644 --- a/firmware/target/arm/imx31/gigabeat-s/avic-imx31.c +++ b/firmware/target/arm/imx31/gigabeat-s/avic-imx31.c @@ -67,9 +67,20 @@ void UIE_VECTOR(void) } /* We use the AVIC */ -void __attribute__((naked)) irq_handler(void) +void __attribute__((interrupt("IRQ"))) irq_handler(void) { const int offset = (int32_t)NIVECSR >> 16; + + if (offset == -1) + { + /* This is called occasionally for some unknown reason even with the + * avic enabled but returning normally appears to cause no harm. The + * KPP and ATA seem to have a part in it (common but multiplexed pins + * that can interfere). It will be investigated more thoroughly but + * for now it is simply an occasional irritant. */ + return; + } + disable_interrupt(IRQ_FIQ_STATUS); panicf("Unhandled IRQ %d in irq_handler: %s", offset, offset >= 0 ? avic_int_names[offset] : ""); -- cgit v1.2.3