Re: 2.6.19 timer API changes

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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