Re: 2.6.19 timer API changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

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;
#else
   expirelo = read_c0_count() + cycles_per_jiffy;
#endif
   write_c0_compare(expirelo);
   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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux