linux-mips
[Top] [All Lists]

Re: 2.6.19 timer API changes

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: 2.6.19 timer API changes
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Tue, 19 Dec 2006 18:52:36 +0300
Cc: danieljlaird@hotmail.com, linux-mips@linux-mips.org, Vitaly Wool <vwool@ru.mvista.com>
In-reply-to: <20061219.233410.25911550.anemo@mba.ocn.ne.jp>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Atsushi Nemoto wrote:

When I run the kernel it hangs in the calibrate_delay function. Eventually the complete kernel does run but it runs very slow. This is usually an issue with the Timer Interuppt setup etc. But I have looked at the other MIPS ports and seem to have made the same changes.

On the PNX8550 it does not use the CP0 timer but use a different timer (the
Custom MIPS core has 3 extra timers)

Hmm, do the TIMER1 and CP0_COUNTER run at same speed?  If no, the
PNX8550 port should be broken (i.e. gettimeofday() did not work
properly) even without the timer API changes.  You should provide
custom clocksource.mips_read (previously named mips_hpt_read) function
which returns TIMER1 counter value.  If the TIMER1 was not 32-bit
free-run counter, some trick would be required.  Refer sb1250 or
jmr3927 for example.

I would like to discourage you from repeating those JMR3927 clocksource "tricks" when you have 3 spare count/compare regs. This will warrant troubles when clockevents support gets merged into mainline (in fact, it was not necessary even on JMR3927 which has 3 timers). Although, if the timer isn't auto-reloading (I assume it isn't), the trick shouldn't be needed.

---
Atsushi Nemoto

WBR, Sergei

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