[RFC] Event timers on sparc64/sun4v

[Alexander Motin]

Marius Strobl wrote:
> Looks better, but can't you just implement the tick grace check
> in tick_et_start() and let it return an error if the interval
> is too short until there maybe is an MI way to supply a minimum
> period?

Is it so important now? If I understand right, limit was set at 50KHz. I
haven't heard somebody was trying to use so high HZ values. And even so,
10000 ticks for 500MHz CPU seems much more then enough to handle simple
read-modify-write operation with disabled interrupts. May be there is
something wrong with interrupt acknowledgment in case the rest of
interrupt handler takes too much time or some else? If it is the result
of some unexpected delays, may be it would be better to reread timer
after writing comparator to make sure we got in time and plank wasn't
reached yet?

tick_et_start() status is not checked my MI code at the moment, as error
handling in that case is not obvious. Do you like panic of printf there?

> Also please follow style(9) and don't initializing variables in
> the declarations and leave tick_{clear,start} at the end of the
> file in order to not move code around unnecessarily.

Fixed: http://people.freebsd.org/~mav/timers_sparc3.patch

>> Don't you have some spare system with stick problems, so I could play
>> with it?
> 
> I have but I recently moved and am currently busy with semester
> finals so it'll probably be mid-August when I'm able to set it up
> again. I'm not sure I'll be able to provide remote access though.

It's a pity.

>> And some documentation? I am curious, what is wrong there. :)
> 
> Just look at the documentation of US-III or later CPUs:
> www.cs.pitt.edu/~cho/cs2410/currentsemester/handouts/USIIIv2.pdf

Thanks. Now it seems more clear.

Looking on documentation I may assume that STICK counter incremented
synchronously over the system, while they may need initial sync. Looking
on sync code I've got some doubts about it's correctness.

If I understand right, BSP waits for AP to signal readiness, then reads
it's timers and fills respective variable. AP during startup sets
readiness flag, then fetches value and programs timer. But what happens
if AP fetches value before the AP stores them? I don't see any
protection against it there. Wouldn't it be reasonable to do instead:
 - for BSP:
	membar(StoreLoad);
	csa->csa_tick = rd(tick);
	membar(StoreLoad);
	csa->csa_state = CPU_TICKSYNC;
	do {
		membar(StoreLoad);
		csa->csa_tick = rd(tick);
	} while (csa->csa_state != CPU_TICKSYNCDONE)
 - for APs (C equivalent):
	while (csa->csa_state != CPU_TICKSYNC)
		;
	membar(StoreLoad);
	wrpr(csa->csa_tick, 0, 0);
	membar(StoreLoad);
	csa->csa_state = CPU_TICKSYNCDONE;
?

-- 
Alexander Motin