[Top] [All Lists]

Re: 2.6.19 timer API changes

To: "Kevin D. Kissell" <>
Subject: Re: 2.6.19 timer API changes
From: Sergei Shtylyov <>
Date: Wed, 20 Dec 2006 21:01:55 +0300
Cc: Daniel Laird <>,, Vitaly Wool <>
In-reply-to: <056f01c72446$31687b30$10eca8c0@grendel>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <056f01c72446$31687b30$10eca8c0@grendel>
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803

Kevin D. Kissell wrote:

they are referring to when they begin the next sentence with "When active".
I can see how someone might think it advantageous to have a mode where
the Count register auto-resets on a timer tick, so that there's no need to
recalcuate Compare values.  But I've never seen that implemented on a
MIPS processor.

   Toshiba TX3927 mentioned in that thread before is an example...

Free-running Count registers have other uses that can
be shared with the timer interrupts, so long as it's Compare and not Count
that gets reprogrammed on an interrupt. I have a hard time believing that
the 8550 has the auto-reset as default behavior.

   Yet the code suggests that it does. PNX8550 seems to be a strange beast... 

If I do the following:
static void __init c0_hpt_timer_init(void)
#ifdef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */
   expirelo = cycles_per_jiffy;
   expirelo = read_c0_count() + cycles_per_jiffy;
   write_c0_count(cycles_per_jiffy); //Added DJL

First of all, I think the conditional code is broken, even if you
believe that Count is reset to zero on every interrupt.  This is
the *init* code, that's getting called once at boot time to set
up the clock.  It's not a clock interrupt handler.

It is highly likely that the Count register has already gone

This is called why the count is disabled -- this is done in arch_init_irq(). Only plat_timer_setup() re-enables it.

beyond the value of cycles_per_jiffy by the time this code
gets hit.  If that's true, programming Compare to zero+delta
means waiting for the counter to wrap around before the first
interrupt is delivered - a 10-second-ish hang.  Writing the same
value to Count that you just wrote to Compare will, on many
cores, cause a Count=Compare state and a prompt interrupt.

But the real fix is almost certainly to get rid of the conditional.

   That would be too simple... :-)
Moreover, with presumed auto-reload behavior it's likely to warrant the wrong expirelo value (which in turn will cause jiffies to be longer than intended) -- all because of Count register possible being non-zero at this point...

            Kevin K.

WBR, Sergei

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