[okl4-developer] timer and vtimers

[Sergio Ruocco]

Hi,

both me and some students of mine are venturing, for different projects,
in the OKL4 timer/Iguana (v)timers APIs (when running on XScale PXA250
hw), but we are a bit confused by what we read.

Before reverse-engineering all the code to learn how to use it properly,
and understand what's going on in general, we decided to first try ask
to the list.

We briefly looked at:

- the "physical" driver:
okl4_3.0/drivers/pxa250_timer/

- L4 uK using an hw timer for thread scheduling:
okl4_3.0/platform/pxa/pistachio/src/timer.c

- the Iguana timer and vtimer implementations:
okl4_3.0/iguana/timer
okl4_3.0/iguana/vtimer

and finally at the small vtimer example in
	okl4_3.0/iguana/example/drivers/src/drivers_example.c


In all of this, it is not clear to us:

- how can we place multiple outstanding requests (eg. for 10, 12 and 15
ms in the future)

- once that is done, how can we identify which request we have been
notified of?

- what is the actual role of the vtimer(s) objects
are they (just) client timer requests?

If so, why exactly four virtual timers are declared and initialised in
the server ("timer_server.c") and called "instances"? Instances of what?

	static struct virtual_timer virtual_device_instance[4] = { { 1 }
	 };  /* valid but unused instances are ok */

Are they (virtual) _devices_, then ?
Isn't a vtimer a virtual device already?

Why only two instances are available after the vtimer server
initialization ?

I can see that a XScale CPU has 4 timer match registers triggering
interrupts on matches, one of them is used by the microkernel itself,
the other (probably) by the roll-over code saw somewhere in the code.

Thus, on XScale, just 2 timers irqs are free. Still, having only two hw
timer match registers left shouldn't affect the number of outstanding
requests we can enqueue to a (v)timer...


There is more, but this is enough to start...

Thanks in advance for any clarification.

Ciao
	Sergio