Re: 2.6.19 timer API changes

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

Daniel Laird wrote:

> Atsushi Nemoto wrote:

>>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

    Meaning clocksource_mips.read... :-)

>>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.

>>---
>>Atsushi Nemoto
>>
>>
>>
> 
> I am just starting to look into this (thankyou for your first comments).
> I have reduced the problem code, so if I change the following:
> /* For use both as a high precision timer and an interrupt source.  */
> static void __init c0_hpt_timer_init(void)
> {
> 	expirelo = read_c0_count() + cycles_per_jiffy;
> 	write_c0_compare(expirelo);
> } (the 2.6.19 version)
> to the following:
> /* For use both as a high precision timer and an interrupt source.  */
> static void __init c0_hpt_timer_init(void)
> {
>     unsigned int count = read_c0_count() - mips_hpt_read();

     Doesn't make sense to me... Should be 0 or near.

> 	expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy;
> 	write_c0_count(expirelo - cycles_per_jiffy);
> 	write_c0_compare(expirelo);
> 	write_c0_count(count);
> }

    This code just shouldn't be executing at all, since the interrupts are 
coming from the other source than standard CP0 count/compare registers (so, 
I'd assume mips_timer_state should need to be set -- but it doesn't)... and at 
the same time the handler writes to them... well, PNX8550 must have really 
weird timers...

> Then i get the system to boot up and all seems well.  I am new to this and
> am looking into why this change makes the system boot up.  As always though
> any help is appreciated.

> Cheers
> Dan

WBR, Sergei