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

1 files changed, 12 insertions, 1 deletions

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] : "<Unknown>");