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
This commit is contained in:
Michael Sevakis 2008-11-27 11:49:49 +00:00
parent b4fb3cd8bd
commit 23e59f20bf

View file

@ -67,9 +67,20 @@ void UIE_VECTOR(void)
} }
/* We use the AVIC */ /* We use the AVIC */
void __attribute__((naked)) irq_handler(void) void __attribute__((interrupt("IRQ"))) irq_handler(void)
{ {
const int offset = (int32_t)NIVECSR >> 16; 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); disable_interrupt(IRQ_FIQ_STATUS);
panicf("Unhandled IRQ %d in irq_handler: %s", offset, panicf("Unhandled IRQ %d in irq_handler: %s", offset,
offset >= 0 ? avic_int_names[offset] : "<Unknown>"); offset >= 0 ? avic_int_names[offset] : "<Unknown>");