linux-mips
[Top] [All Lists]

Re: [MIPS] Probe for usability of cp0 compare interrupt.

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [MIPS] Probe for usability of cp0 compare interrupt.
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 17 Oct 2007 17:46:36 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <20071018.011033.115643462.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <S20022491AbXJQLKE/20071017111004Z+82239@ftp.linux-mips.org> <20071018.011033.115643462.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.14 (2007-02-12)
On Thu, Oct 18, 2007 at 01:10:33AM +0900, Atsushi Nemoto wrote:

> > Some processors offer the option of using the interrupt on which
> > normally the count / compare interrupt would be signaled as a normal
> > interupt pin.  Previously this required some ugly hackery for each
> > system which is much easier done by a quick and simple probe.
> 
> It seems write_c0_compare(0) will not work as expected if c0_count was
> near 0xffffffff.  How about write_c0_compare(read_c0_compare()) (or
> c0_timer_ack()) ?

The two things are a know lose end.  There is a bug in some old MIPS
processors where reading one of the compare or count registers in exactly
the moment when both have identical values in the interrupt getting lost.

Will have to dig up the details on that one again before I can implement
a proper workaround ...

> Also something calculated from mips_hpt_frequency would be better than
> the magic number 0x300000.

Well, we just don't care how long it really takes - but it has to be
slow enough to work even for stuff like qemu.  Then busy wait for a
number of cycles long enough to ensure the timer will have expired to
avoid the interrupt bug.

  Ralf

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