2.6.19 timer API changes

When I run the kernel it hangs in the calibrate_delay function. Eventually the complete kernel does run but it runs very slow. This is usually an issue with the Timer Interuppt setup etc. But I have looked at the other MIPS ports and seem to have made the same changes.

On the PNX8550 it does not use the CP0 timer but use a different timer (the Custom MIPS core has 3 extra timers)

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

On the PNX8550 it does not use the CP0 timer but use a different timer (the Custom MIPS core has 3 extra timers)

Quoted 3 lines · Daniel Laird

On the PNX8550 it does not use the CP0 timer but use a different timer (the
Custom MIPS core has 3 extra timers)

Do you know what this ifndef line mean?

#ifndef CONFIG_SOC_PNX8550	/* pnx8550 resets to zero */
	/* Ack this timer interrupt and set the next one.  */
	expirelo += cycles_per_jiffy;

#endif

If it means "On PNX8550, writing to COMPARE register resets COUNTER to zero", new time.c might be broken for PNX8550. Could you try this patch?

arch/mips/kernel/time.c +0 -0

index 11aab6d..4eb0741 100644
@@ -119,7 +119,11 @@ static cycle_t c0_hpt_read(void)
 /* For use both as a high precision timer and an interrupt source.  */

Quoted 5 lines

When I run the kernel it hangs in the calibrate_delay function. Eventually the complete kernel does run but it runs very slow. This is usually an issue with the Timer Interuppt setup etc. But I have looked at the other MIPS ports and seem to have made the same changes.

On the PNX8550 it does not use the CP0 timer but use a different timer (the Custom MIPS core has 3 extra timers)

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

Quoted 4 lines · Atsushi Nemoto

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

Quoted 9 lines

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();

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

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

I would like to discourage you from repeating those JMR3927
clocksource "tricks" when you have 3 spare count/compare regs. This will warrant troubles when clockevents support gets merged into mainline (in fact, it was not necessary even on JMR3927 which has 3 timers). Although, if the timer isn't auto-reloading (I assume it isn't), the trick shouldn't be needed.

I am just digging out the mips core user manual...
However I have tried this change you suggested, it still takes a long time to get past the calibrate delay function (~10seconds).
However after this it seems to run at full speed where as before it used to run very slow.
So an improvement, I think this does mean the new time.c has broken 8550 support hopefully I can find otu what the core does so it can be fixed.

<snip>
Hm, then it seems writing to COMPARE does not clear COUNT.

How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time.

Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550

Quoted 6 lines

Hm, then it seems writing to COMPARE does not clear COUNT.

How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time.

Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550

I have not tried the suggested change yet, but I have fiund the mips manual and here is what it says:

The 32-bit register is both readable and writable through the MTC0 and MFC0 instructions as CP0 register 9. Upon reset, the Count register is set to 0. Count and Compare together make up Timer_1 in the PR4450 (see Section 3.12). The timer is active by default. When active, Count register contains a free running
counter; on each processor clock-tick, the value in the register increments by one.
However, when bit ST1 bit[3] in the CP0 Configuration register is enabled, the timer is
stopped. When the ST1 bit is disabled, the timer returns to its default state.
Timer_1 is active when the PR4450 is in Sleep mode, but is switched off when the
PR4450 is in Coma mode.
When active, the register can be reset with the assertion of the Terminal Count
(TC_1) signal, which is asserted when the values in the Count and Compare registers
match. After the Count register is reset, it restarts its count on the next processor
clock-tick.
In the PR4450, the TC_1 signal is fed to the external hardware interrupt signal to
invoke an interrupt handler e.g., the timer interrupt. The TC_1 signal can only be
reset to 0 when the interrupt handler performs a write to the Compare register.
Consecutive writes to Count will result in undefined contents. At least one instruction
must be inserted between consecutive writes to Count.

This seems to suggest that writing to the compare register does in fact clear count.

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
}

Then I get a normal startup. i.e it boots fast (no 10second hang). If I remove the write_c0_count then I get the 10 second hang.
I have no idea if gettimeofday is broken. ANy ideas on testing this? Is

there a test package / application that will do this? Before I write my own

Thanks for the suggestions keep them coming!
Cheers
Dan

Quoted 6 lines

I am just digging out the mips core user manual... However I have tried this change you suggested, it still takes a long time to get past the calibrate delay function (~10seconds).
However after this it seems to run at full speed where as before it used to
run very slow.
So an improvement, I think this does mean the new time.c has broken 8550
support hopefully I can find otu what the core does so it can be fixed.

Hm, then it seems writing to COMPARE does not clear COUNT.

How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time.

Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550

Signed-off-by Atsushi Nemoto <[email protected]>

---

arch/mips/kernel/time.c +0 -2

index 11aab6d..8aa544f 100644
@@ -94,10 +94,8 @@ static void c0_timer_ack(void)
 {
 	unsigned int count;
 
-#ifndef CONFIG_SOC_PNX8550	/* pnx8550 resets to zero */
 	/* Ack this timer interrupt and set the next one.  */
 	expirelo += cycles_per_jiffy;
-#endif
 	write_c0_compare(expirelo);
 
 	/* Check to see if we have missed any timer interrupts.  */

arch/mips/philips/pnx8550/common/time.c +0 -0

index 65c440e..e86905a 100644

Quoted 19 lines

The 32-bit register is both readable and writable through the MTC0 and MFC0 instructions as CP0 register 9. Upon reset, the Count register is set to 0. Count and Compare together make up Timer_1 in the PR4450 (see Section 3.12). The timer is active by default. When active, Count register contains a free running counter; on each processor clock-tick, the value in the register increments by one. However, when bit ST1 bit[3] in the CP0 Configuration register is enabled, the timer is stopped. When the ST1 bit is disabled, the timer returns to its default state. Timer_1 is active when the PR4450 is in Sleep mode, but is switched off when the PR4450 is in Coma mode.
When active, the register can be reset with the assertion of the TerminalCount (TC_1) signal, which is asserted when the values in the Count and Compare registers match. After the Count register is reset, it restarts its count on the next processor clock-tick.
In the PR4450, the TC_1 signal is fed to the external hardware interrupt signal to invoke an interrupt handler e.g., the timer interrupt. The TC_1 signal can only be reset to 0 when the interrupt handler performs a write to the Compare register.
Consecutive writes to Count will result in undefined contents. At least one instruction must be inserted between consecutive writes to Count.

Quoted 2 lines

This seems to suggest that writing to the compare register does in fact clear count.

It actually doesn't suggest anything alike. All it says is that "the
register *can* be reset with the assertion of the Terminal Count (TC_1) signal which is asserted when the values in the Count and Compare registers match". Whtat it doesn't say is what determines if it's really reset by TC_1 assertion or not.

Quoted 11 lines

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
}

Then I get a normal startup. i.e it boots fast (no 10second hang). If I remove the write_c0_count then I get the 10 second hang.

I have no idea if gettimeofday is broken. ANy ideas on testing this? Is there a test package / application that will do this? Before I write my own

Quoted 2 lines

How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time.

And nobody noticed. :-)

arch/mips/philips/pnx8550/common/time.c #include <asm/debug.h> · line 47

Quoted 5 lines

arch/mips/philips/pnx8550/common/time.c +5 -0

+static cycle_t pnx8550_hpt_read(void)
+{
+	/* FIXME: we should use timer2 or timer3 as freerun counter */
+	return read_c0_count();
+}

I'd suggest read_c0_count2() here, possibly adding an interrupt
handler for it since it will interrupt upon hitting compare2 reg. value (but we could probably just mask the IRQ off), and enabling the timer 2, of course (the current code disables it)...

Quoted 3 lines · Daniel Laird

Then I get a normal startup. i.e it boots fast (no 10second hang). If I
remove the write_c0_count then I get the 10 second hang.

I think Kevin's analysis about this 10 second hang is correct. Then I think my last patch will work as well.

Quoted 3 lines

I have no idea if gettimeofday is broken. ANy ideas on testing this? Is there a test package / application that will do this? Before I write my own

Calling gettimeofday() continuously many times (at least some tick periods) and calculates times between each call. Those differences should be almost same. Of course you must run this program on very idle system (or you must raise its priority).

---
Atsushi Nemoto

Quoted 6 lines

arch/mips/philips/pnx8550/common/time.c +6 -0

+
+static void pnx8550_timer_ack(void)
+{
+    write_c0_compare(cycles_per_jiffy);
+}
+

arch/mips/philips/pnx8550/common/time.c #include <asm/debug.h> · line 47

Quoted 5 lines

arch/mips/philips/pnx8550/common/time.c +5 -0

+static cycle_t pnx8550_hpt_read(void)
+{
+    /* FIXME: we should use timer2 or timer3 as freerun counter */
+    return read_c0_count();
+}

I'd suggest read_c0_count2() here, possibly adding an interrupt
handler for it since it will interrupt upon hitting compare2 reg. value (but we could probably just mask the IRQ off), and enabling the timer 2, of course (the current code disables it)...

Quoted 4 lines · Sergei Shtylyov

Quoted 2 lines

How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time.

And nobody noticed. :-)

I changed my mind a bit. The pre-clocksource gettimeofday() might work well on PNX8550. There was timerlo variable which hold COUNT value on last timer interrupt and fixed_gettimeoffset() subtracted timerlo from COUNT value at the time.

Quoted 10 lines · Sergei Shtylyov

arch/mips/philips/pnx8550/common/time.c #include <asm/debug.h> · line 47

Quoted 5 lines

arch/mips/philips/pnx8550/common/time.c +5 -0

+static cycle_t pnx8550_hpt_read(void)
+{
+	/* FIXME: we should use timer2 or timer3 as freerun counter */
+	return read_c0_count();
+}

I'd suggest read_c0_count2() here, possibly adding an interrupt
handler for it since it will interrupt upon hitting compare2 reg. value (but we could probably just mask the IRQ off), and enabling the timer 2, of course (the current code disables it)...

It would be right direction. And we should set set count2 frequency to mips_hpt_frequency. But I cannot test it by myself so I'd like to leave it for others. Good exercise ;)

---
Atsushi Nemoto

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.

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.

Quoted 11 lines

Quoted 11 lines

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

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.

Kevin K.