Re: [Xenomai-core] Some questions about the ARM port (Integrator vs. PXA)

[Detlef Vollmann <dv@domain.hid>]

Stelian Pop wrote:
> Le vendredi 30 juin 2006 à 08:29 +0200, Detlef Vollmann a écrit :

> __ipipe_mach_set_dec sets the *next* timer occurence. It functions in a
> one-shot way (like a real decrementer, not a auto-reloading one).
In your implementation for the Integrator you set timer_reload in
__ipipe_mach_set_dec() and use that value in the (Linux) interrupt
handler.
And that seems to be the correct behaviour, if I look at Xenomai's
arch/arm/hal.c and see in rthal_timer_release the call
__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy).

> > Is the Linux timer interrupt still only called after LATCH ticks?
> 
> IPipe doesn't do anything special to the timer (except for acking the
> interrupt because this must be done early in some cases).
> 
> If Linux handles the timer, then nothing changes, the timer frequency is
> LATCH.
> 
> If Xenomai handles the timer, then it is its responsability to propagate
> the interrupt to Linux when it wants to (look for xnarch_relay_tick() in
> Xenomai's nucleus).
Thanks for the explanation.

> > Now I have another question on this: on the PXA I have a hardware
> > problem so that I must sometimes set the next match value to the
> > match value after the next one, so effectively loosing one
> > interrupt.
> 
> > If Linux is responsible for reprogramming the timer, I should tell
> > ipipe about it, so that ipipe can tell any other domain.
> > How can I do that?
> 
> If Linux is responsible for reprogramming the timer there is a good
> chance there is no other domain, so it doesn't matter much :)
That's probably true.

> But you will have a problem when Xenomai takes upon the timer, because
> its scheduler doesn't expect to lose timer ticks.
Exactly that's the problem...

> I can imagine adding a return code to __ipipe_mach_set_dec() which would
> tell if the hardware has been programmed successfully or not, and in
> this latter case Xenomai (or ipipe ?)
It should definitely be ipipe.  At least in theory there could be
other domains than Xenomai, and any domain needs to be informed.

> would have to busy sleep until the
> next (calculated) timer occurence...
Hmmm, busy sleeping for several usecs is pretty long.
Couldn't ipipe in that case just fire the interrupt routine
(w/o ack'ing the interrupt), even if a bit out of the correct timing?

But anyway, whoever is responsible for reprogramming the timer needs
to know that it already is reprogrammed this time.

In Linux, it's easy because there are separate functions for dealing
with the hardware (ack the IRQ and reprogram timer) and for actually
doing what has to be done in the system on a timer interrupt
(timer_tick()).
For IPIPE, that separation isn't so easy as the (some) domains have the
illusions that they get their timer interrupts still from the
real hardware.

A simple solution would be a special return value from
__ipipe_mach_set_dec(), and in this case ipipe just calls the
registered handlers from all domains.  But for the domain
that called (indirectly) __ipipe_mach_set_dec() this could mean
that an interrupt handler is called recursively, and this is
something no handler really expects...

So, I have no solution for now and have to live with the fact
that Xenomai might loose a timer tick :-(

Again, thanks a lot for your help
 Detlef

-- 
Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/
Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/