Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Tickless/dyntick kernel, highres timer and general time crapectomy
Date: Fri, 8 Jun 2007 10:57:34 +0100	[thread overview]
Message-ID: <20070608095734.GB13686@linux-mips.org> (raw)
In-Reply-To: <cda58cb80706080207ia8a6633na921c5faa69344cd@mail.gmail.com>

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

      reply	other threads:[~2007-06-08 10:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 18:54 Tickless/dyntick kernel, highres timer and general time crapectomy Ralf Baechle
2007-06-06 19:04 ` Sergei Shtylyov
2007-06-06 19:04   ` Ralf Baechle
2007-06-06 19:04     ` Ralf Baechle
2007-06-07  7:59 ` Franck Bui-Huu
2007-06-07  8:49   ` Atsushi Nemoto
2007-06-07 11:30   ` Ralf Baechle
2007-06-07 13:11     ` Franck Bui-Huu
2007-06-07 13:43       ` Sergei Shtylyov
2007-06-07 14:44         ` Franck Bui-Huu
2007-06-07 14:49           ` Sergei Shtylyov
2007-06-07 15:48           ` Ralf Baechle
2007-06-08  8:29             ` Franck Bui-Huu
2007-06-08  9:41               ` Ralf Baechle
2007-06-08 14:22             ` Atsushi Nemoto
2007-06-07 15:02       ` Ralf Baechle
2007-06-07 15:14       ` Ralf Baechle
2007-06-08  9:07         ` Franck Bui-Huu
2007-06-08  9:57           ` Ralf Baechle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070608095734.GB13686@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=vagabon.xyz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox