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
