[Top] [All Lists]

Re: Tickless/dyntick kernel, highres timer and general time crapectomy

To: Franck Bui-Huu <>
Subject: Re: Tickless/dyntick kernel, highres timer and general time crapectomy
From: Ralf Baechle <>
Date: Fri, 8 Jun 2007 10:57:34 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Mutt/1.5.14 (2007-02-12)
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 ...

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


<Prev in Thread] Current Thread [Next in Thread>