On Fri, Jun 08, 2007 at 11:07:23AM +0200, Franck Bui-Huu wrote: > devices. Actually an external interrupt controller, which is a simple > MUX, allows several devices to share the same irq line. To know which > device generates an irq you need to probe this irq controller. > > So it seems to me that if the hardware designers decide to not reserve > the highest irq line for the timer irq, you're in trouble... Yuck. That's a new configuration ... Thinking about a really bad one. If your processor is a MIPS R2 processor, fine. If it's older you can't reliably test for a timer interrupt pending other than by masking all performance counter interrupts, then testing if IE7 is still pending in the cause register. If of course that probe isn't reliable because there is another device you will have to do more guessing by trying to acknowledge the cp0 compare interrupt. If IE7 transitioned to 0, there was a timer interrupt pending if not there was an external interrupt pending and there there may or may not have been a compare interrupt have been pending. And if the external goes 1->0 at just that time you may believe you got a timer interrupt anyway. Things get slightly better if the external interrupt controller has a register where interrupt pending can be queried but it's still ... interesting. I guess the easy solution in such a case is to not use the compare interrupt in such a configuration and just ack it. Or go for an R2 processor. Ralf
