[Top] [All Lists]

Re: 2.6.19 timer API changes

To: Atsushi Nemoto <>
Subject: Re: 2.6.19 timer API changes
From: Sergei Shtylyov <>
Date: Tue, 19 Dec 2006 18:52:36 +0300
Cc:,, Vitaly Wool <>
In-reply-to: <>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803

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>