[RFC] Event timers on MIPS

Alexander Motin mav at FreeBSD.org
Thu Jul 22 05:36:19 UTC 2010


Hi.

Neel Natu wrote:
> Your patch works fine on a Sibyte. I verified that wall clock time is
> progressing as expected. Is there any other test that you recommend?
> 
> I have a few comments about the patch:
> 
> 1. set_cputicker() in clock_attach() should be moved back up to
>     mips_timer_init_params(). Otherwise the platform-specific CPU tickers
>    used by Sibyte, Octeon and RMI will be overwritten by the mips32 ticker.

Fixed.

> 2. The local variable 'cycles_per_tick' in clock_intr() can now be a uint32_t.

Fixed.

> 3. Is there a race between setting 'cycles_per_tick' in clock_start() and
>     clock_intr()? Would it be better to write the compare register first
>     and then set 'cycles_per_tick' to a non-zero value?

And how does it help?

>     If I understand the code correctly we are liable to get clock interrupts
>     even afer the clock is stopped when the CP0 COUNT register matches
>     0xffffffff.

You mean we can receive interrupt from previous clock_start() after new
one? Theoretically I think it is possible, but what can we do about it?

> 4. We need to update the DPCPU(compare_ticks) value when we start the timer
>     in clock_start().

Fixed.

> 5. I think the entire 'lost_ticks' processing in clock_intr() should be
>     conditional on (cycles_per_tick > 0). Without this we may incorrectly
>     update the value of DPCPU(lost_ticks).

Fixed. Indeed, in one-shot mode extra callback can be confusing.

> 6. Can you a couple of lines of explaining the computatation of
>     'et_min_period' and 'et_max_period'? It is not completely obvious to me.

Minimal period is set artificialy to reduce possibility to lost very
short time interval during comparator programming. I've done it after
marius@ asked to do the same for sparc64. If this comparator is more
clever to handle missed time, it may not be needed.
Maximal period is calculated from maximal counter value, minus one to
possibly avoid some rounding overflows. Again, if this comparator is
"clever" may be it need to be reduced.
I don't have documentation for this hardware, so fix me if I am wrong.

New patch: http://people.freebsd.org/~mav/timers_mips3.patch

Thank you!

-- 
Alexander Motin


More information about the freebsd-mips mailing list