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

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

[Detlef Vollmann]

Hello,

looking at the ARM Integrator patch (which seems to be something
like the reference port for ARM), I'm not really clear about some
of the code:

 a) What's the difference between __ipipe_mach_ticks_per_jiffy
    and LATCH?

 b) Is there some (hidden, intended future) semantics of tscok?
    Right now it just avoids that garbage is returned before
    the timer is initialized.

 c) In the interrupt routine, the comment currently says:
    "If Linux is the only domain, ack the timer and reprogram it",
    but the actual code looks as if the comment should read:
    "If Linux is running natively, ack the timer.
    If Linux's the only domain, reprogram it."
    What's wrong, the code or the comment?

 d) __ipipe_mach_set_dec() sets the next match value of the timer.
    But the current counter isn't changed.  Correct?
    Or is setting the match value and setting the current counter
    the same operation on the Integrator?

    __ipipe_mach_get_dec() doesn't return the next match value, but
    the current actual counter, i.e. some value between 0 and the
    next match value.  Correct?
    And if so, which value?  The number of ticks elapsed since the
    last match or the number of ticks until the next match occurs?

    The names "..._dec" suggest that the integrator provides a clock
    register that decrements.  The PXA provides clock registers
    that are incremented, and the timer used for the Linux ticks
    is (in Linux) never reset, but instead the match value at
    which an interrupt occurs is incremented on each interrupt.
    So, a port to the PXA wouldn't be straightforward, and so I
    want to make sure that I really understand the semantics
    of the ARM port.

Thanks for any clarifications,
 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/

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

[Stelian Pop]

Le jeudi 29 juin 2006 à 10:38 +0200, Detlef Vollmann a écrit :
> Hello,

Hi,

> 
> looking at the ARM Integrator patch (which seems to be something
> like the reference port for ARM), I'm not really clear about some
> of the code:
> 
>  a) What's the difference between __ipipe_mach_ticks_per_jiffy
>     and LATCH?

As a matter of fact there is no difference.

>  b) Is there some (hidden, intended future) semantics of tscok?
>     Right now it just avoids that garbage is returned before
>     the timer is initialized.

tscok is used to prevent __ipipe_mach_get_tsc() returning bogus values
in the early boot stages (when the timer is not yet initialized but
ipipe is). IIRC this was mainly needed when enabling
CONFIG_IPIPE_STATS...

>  c) In the interrupt routine, the comment currently says:
>     "If Linux is the only domain, ack the timer and reprogram it",
>     but the actual code looks as if the comment should read:
>     "If Linux is running natively, ack the timer.
>     If Linux's the only domain, reprogram it."
>     What's wrong, the code or the comment?

Always trust the code :)

The true meaning of that code is:
	* if Linux is running natively (no ipipe), ack and reprogram the timer
	* if Linux is running under ipipe, but it still has the control over
the timer (no Xenomai for example), then reprogram the timer (ipipe has
already acked it)
	* if some other domain has taken over the timer, then do nothing (ipipe
has acked it, and the other domain has reprogramed it)

>  d) __ipipe_mach_set_dec() sets the next match value of the timer.
>     But the current counter isn't changed.  Correct?
>     Or is setting the match value and setting the current counter
>     the same operation on the Integrator?

Yes, the integrator has a true decrementer and not a match counter.

__ipipe_set_dec(x) must set program the timer so that a timer interrupt
occurs after x ticks.

>     __ipipe_mach_get_dec() doesn't return the next match value, but
>     the current actual counter, i.e. some value between 0 and the
>     next match value.  Correct?

Yes.

>     And if so, which value?  The number of ticks elapsed since the
>     last match or the number of ticks until the next match occurs?

The number of ticks until the next match occurs.

>     The names "..._dec" suggest that the integrator provides a clock
>     register that decrements.  The PXA provides clock registers
>     that are incremented, and the timer used for the Linux ticks
>     is (in Linux) never reset, but instead the match value at
>     which an interrupt occurs is incremented on each interrupt.
>     So, a port to the PXA wouldn't be straightforward, and so I
>     want to make sure that I really understand the semantics
>     of the ARM port.

Indeed, you will need to adapt the PXA incrementer to the ipipe
decrementer semantics.

Stelian.
-- 
Stelian Pop <stelian.pop@domain.hid>

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

[Detlef Vollmann]

Stelian Pop wrote:
> Le jeudi 29 juin 2006 à 10:38 +0200, Detlef Vollmann a écrit :

> >  a) What's the difference between __ipipe_mach_ticks_per_jiffy
> >     and LATCH?
> 
> As a matter of fact there is no difference.
Does this mean that __ipipe_mach_ticks_per_jiffy never changes?
What about the correlation between __ipipe_mach_set_dec() and
__ipipe_mach_ticks_per_jiffy?  __ipipe_mach_set_dec() seems
to do a permanent change, and not only a one-time change.

Is the Linux timer interrupt still only called after LATCH ticks?


> >  b) Is there some (hidden, intended future) semantics of tscok?
> >     Right now it just avoids that garbage is returned before
> >     the timer is initialized.
> 
> tscok is used to prevent __ipipe_mach_get_tsc() returning bogus values
> in the early boot stages (when the timer is not yet initialized but
> ipipe is). IIRC this was mainly needed when enabling
> CONFIG_IPIPE_STATS...
Ok, thanks.


> >  c) In the interrupt routine, the comment currently says:
> >     "If Linux is the only domain, ack the timer and reprogram it",
> >     but the actual code looks as if the comment should read:
> >     "If Linux is running natively, ack the timer.
> >     If Linux's the only domain, reprogram it."
> >     What's wrong, the code or the comment?
> 
> Always trust the code :)
> 
> The true meaning of that code is:
>         * if Linux is running natively (no ipipe), ack and reprogram the timer
>         * if Linux is running under ipipe, but it still has the control over
> the timer (no Xenomai for example), then reprogram the timer (ipipe has
> already acked it)
>         * if some other domain has taken over the timer, then do nothing (ipipe
> has acked it, and the other domain has reprogramed it)
Thanks for the explanation, it really helps.

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?

> Indeed, you will need to adapt the PXA incrementer to the ipipe
> decrementer semantics.
Ok, that shouldn't be a problem.

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/

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

[Stelian Pop]

Le vendredi 30 juin 2006 à 08:29 +0200, Detlef Vollmann a écrit :
> Stelian Pop wrote:
> > Le jeudi 29 juin 2006 à 10:38 +0200, Detlef Vollmann a écrit :
> 
> > >  a) What's the difference between __ipipe_mach_ticks_per_jiffy
> > >     and LATCH?
> > 
> > As a matter of fact there is no difference.
> Does this mean that __ipipe_mach_ticks_per_jiffy never changes?

Indeed.

> What about the correlation between __ipipe_mach_set_dec() and
> __ipipe_mach_ticks_per_jiffy?  __ipipe_mach_set_dec() seems
> to do a permanent change, and not only a one-time change.

__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).

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

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

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

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 ?) would have to busy sleep until the
next (calculated) timer occurence... What do the experts think ?

Stelian.
-- 
Stelian Pop <stelian.pop@domain.hid>

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

[Detlef Vollmann]

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/

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Detlef Vollmann wrote:
>>> 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.

Just out of curiosity: What is the technical background of this issue?
Does it mean that the hardware is not able to trigger a timer event over
a certain period of time and you therefore have to defer the event until
this is possible again? Do you know ahead of time when this will happen?
Or only when you try to set the timer and the hardware tells you about
it somehow?

Looks like designing a real-time application around such a quirk isn't
that easy. But it's not a generic PXA issue, is it?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Detlef Vollmann]

Jan Kiszka wrote:
> 
> Detlef Vollmann wrote:
> >>> 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.
> 
> Just out of curiosity: What is the technical background of this issue?
> Does it mean that the hardware is not able to trigger a timer event over
> a certain period of time and you therefore have to defer the event until
> this is possible again? Do you know ahead of time when this will happen?
> Or only when you try to set the timer and the hardware tells you about
> it somehow?
Here's the original comment and code from
 linux/arch/arm/mach-pxa/time.c:

    /* Loop until we get ahead of the free running timer.
     *
     * HACK ALERT: it seems that the PXA timer regs aren't updated right
     * away in all cases when a write occurs.  We therefore compare with
     * 8 instead of 0 in the while() condition below to avoid missing a
     * match if OSCR has already reached the next OSMR value.
     * Experience has shown that up to 6 ticks are needed to work around
     * this problem, but let's use 8 to be conservative.  Note that this
     * affect things only when the timer IRQ has been delayed by nearly
     * exactly one tick period which should be a pretty rare event.
     */
    do {
        timer_tick(regs);
        OSSR = OSSR_M0;  /* Clear match on timer 0 */
        next_match = (OSMR0 += LATCH);
    } while( (signed long)(next_match - OSCR) <= 8 );

> Looks like designing a real-time application around such a quirk isn't
> that easy.
It's not so difficult to work around the problem for a single system.
What's difficult is to find a solution in a framework that wasn't
built with such a problem in mind.

> But it's not a generic PXA issue, is it?
It seems it is...

 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/

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]

Detlef Vollmann wrote:
> Jan Kiszka wrote:
>> Detlef Vollmann wrote:
>>>>> 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.
>> Just out of curiosity: What is the technical background of this issue?
>> Does it mean that the hardware is not able to trigger a timer event over
>> a certain period of time and you therefore have to defer the event until
>> this is possible again? Do you know ahead of time when this will happen?
>> Or only when you try to set the timer and the hardware tells you about
>> it somehow?
> Here's the original comment and code from
>  linux/arch/arm/mach-pxa/time.c:
> 
>     /* Loop until we get ahead of the free running timer.
>      *
>      * HACK ALERT: it seems that the PXA timer regs aren't updated right
>      * away in all cases when a write occurs.  We therefore compare with
>      * 8 instead of 0 in the while() condition below to avoid missing a
>      * match if OSCR has already reached the next OSMR value.
>      * Experience has shown that up to 6 ticks are needed to work around
>      * this problem, but let's use 8 to be conservative.  Note that this
>      * affect things only when the timer IRQ has been delayed by nearly
>      * exactly one tick period which should be a pretty rare event.
>      */
>     do {
>         timer_tick(regs);
>         OSSR = OSSR_M0;  /* Clear match on timer 0 */
>         next_match = (OSMR0 += LATCH);
>     } while( (signed long)(next_match - OSCR) <= 8 );
> 
>> Looks like designing a real-time application around such a quirk isn't
>> that easy.
> It's not so difficult to work around the problem for a single system.
> What's difficult is to find a solution in a framework that wasn't
> built with such a problem in mind.

Indeed, but it should only require minimal changes to
rthal_timer_program_shot on arm (handle a potential return code of
__ipipe_mach_set_dec() as already suggested). Take a look at the i386
variant [1], how this one handles re-triggering of near-by ticks. I
don't see why busy-waiting should be required here to get the same
characteristics like the Linux code above. Or does Linux miss ticks even
with that "hack"?

Jan

[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/include/asm-i386/hal.h?v=SVN-trunk#L178


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Gilles Chanteperdrix]

Detlef Vollmann wrote:
 > It's not so difficult to work around the problem for a single system.
 > What's difficult is to find a solution in a framework that wasn't
 > built with such a problem in mind.

Actually, all architectures have a delay below which they can not be
reprogrammed fast enough. This delay is simply 0 for all of them.

How about rewriting rthal_timer_program_shot as:

static inline void rthal_timer_program_shot (unsigned long delay)
{
    if(delay < __ipipe_mach_min_delay)
        rthal_trigger_irq(RTHAL_TIMER_IRQ);
    else
        __ipipe_mach_set_dec(delay);
}

And define __ipipe_mach_min_delay to be 8 ticks for the PXA architecture ?

-- 


					    Gilles Chanteperdrix.

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

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
 > Detlef Vollmann wrote:
 >  > It's not so difficult to work around the problem for a single system.
 >  > What's difficult is to find a solution in a framework that wasn't
 >  > built with such a problem in mind.
 > 
 > Actually, all architectures have a delay below which they can not be
 > reprogrammed fast enough. This delay is simply 0 for all of them.
 > 
 > How about rewriting rthal_timer_program_shot as:
 > 
 > static inline void rthal_timer_program_shot (unsigned long delay)
 > {
 >     if(delay < __ipipe_mach_min_delay)
 >         rthal_trigger_irq(RTHAL_TIMER_IRQ);
 >     else
 >         __ipipe_mach_set_dec(delay);
 > }
 > 
 > And define __ipipe_mach_min_delay to be 8 ticks for the PXA architecture ?

You can even do this in __ipipe_mach_set_dec, this avoid the need to
modify I-ipipe non-machine specific code. Something like:

void __ipipe_mach_set_dec(unsigned long delay)
{
    if (delay < 8)
        ipipe_trigger_irq(__ipipe_mach_timerint);
    else
        OSMR0 = OSCR + delay;
}

Supposing that OSSR=OSSR_M0 is done elsewhere.

-- 


					    Gilles Chanteperdrix.

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

[Detlef Vollmann]

Gilles Chanteperdrix wrote:
> You can even do this in __ipipe_mach_set_dec, this avoid the need to
> modify I-ipipe non-machine specific code. Something like:
> 
> void __ipipe_mach_set_dec(unsigned long delay)
> {
>     if (delay < 8)
>         ipipe_trigger_irq(__ipipe_mach_timerint);
>     else
>         OSMR0 = OSCR + delay;
> }

Thanks, ipipe_trigger_irq() is exactly what I was looking for.

I'll just add another test after the update of OSMR0 for the
case that we got interrupted between the comparison and the
assignment.  And in that (probably very rare) case I accept that
I loose a timer tick :-(

Also, this way the timer comes a bit early, so any handler that
checks the TSC might think that this is the wrong interrupt --
and wait forever for the correct one.
But the only other option would be the busy wait...

The question about recursion remains:
If a domain decides in its timer interrupt handler to reprogram
the timer by calling __ipipe_mach_set_dec() (indirectly), and
we already are too close to the next match, then that interrupt
handler is called recursively.
Is every ipipe domain expected to cope with this?

 Detlef Vollmann

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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Detlef Vollmann wrote:
> Gilles Chanteperdrix wrote:
>> You can even do this in __ipipe_mach_set_dec, this avoid the need to
>> modify I-ipipe non-machine specific code. Something like:
>>
>> void __ipipe_mach_set_dec(unsigned long delay)
>> {
>>     if (delay < 8)
>>         ipipe_trigger_irq(__ipipe_mach_timerint);
>>     else
>>         OSMR0 = OSCR + delay;
>> }
> 
> Thanks, ipipe_trigger_irq() is exactly what I was looking for.
> 
> I'll just add another test after the update of OSMR0 for the
> case that we got interrupted between the comparison and the
> assignment.  And in that (probably very rare) case I accept that
> I loose a timer tick :-(

It's this piece of code always running under IRQ-lock?

> 
> Also, this way the timer comes a bit early, so any handler that
> checks the TSC might think that this is the wrong interrupt --
> and wait forever for the correct one.
> But the only other option would be the busy wait...
> 
> The question about recursion remains:
> If a domain decides in its timer interrupt handler to reprogram
> the timer by calling __ipipe_mach_set_dec() (indirectly), and
> we already are too close to the next match, then that interrupt
> handler is called recursively.
> Is every ipipe domain expected to cope with this?
> 

The IRQ is marked pending for the receiving domain if
ipipe_trigger_irq() is called when that domain is stalled - and that
should always be the case for ipipe_mach_set_dec(), at least when called
from the timer handler. The timer IRQ will then be handled once the
stall is removed again (on handler return e.g.).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Detlef Vollmann]

Jan Kiszka wrote:
> It's this piece of code always running under IRQ-lock?
No.  ipipe_tune_timer() is a public ipipe interface and can
be called from everywhere.

> The IRQ is marked pending for the receiving domain if
> ipipe_trigger_irq() is called when that domain is stalled - and that
> should always be the case for ipipe_mach_set_dec(), at least when called
> from the timer handler. The timer IRQ will then be handled once the
> stall is removed again (on handler return e.g.).
Thanks for the explanation.

 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/

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

[Detlef Vollmann]

Detlef Vollmann wrote:
> 
> Jan Kiszka wrote:
> > It's this piece of code always running under IRQ-lock?
> No.  ipipe_tune_timer() is a public ipipe interface and can
> be called from everywhere.
Oops, sorry.  I was talking nonsense.
Yes, it is always running under IRQ-lock (and I'm doing the lock
myself).

Sorry for the misinformation
 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/

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

[Gilles Chanteperdrix]

Detlef Vollmann wrote:
 > Gilles Chanteperdrix wrote:
 > > You can even do this in __ipipe_mach_set_dec, this avoid the need to
 > > modify I-ipipe non-machine specific code. Something like:
 > > 
 > > void __ipipe_mach_set_dec(unsigned long delay)
 > > {
 > >     if (delay < 8)
 > >         ipipe_trigger_irq(__ipipe_mach_timerint);
 > >     else
 > >         OSMR0 = OSCR + delay;
 > > }
 > 
 > Thanks, ipipe_trigger_irq() is exactly what I was looking for.
 > 
 > I'll just add another test after the update of OSMR0 for the
 > case that we got interrupted between the comparison and the
 > assignment.  And in that (probably very rare) case I accept that
 > I loose a timer tick :-(

I do not see what you mean. "delay" value does not change over time.

 > 
 > Also, this way the timer comes a bit early, so any handler that
 > checks the TSC might think that this is the wrong interrupt --
 > and wait forever for the correct one.
 > But the only other option would be the busy wait...

It will work for Xenomai:
- in periodic mode, each interrupt is treated as a tick
- in aperiodic mode, there are two guards; first the tsc is compared to
  the next software timer expiration date using nkschedlat as a margin;
  second, if the tick is so early that there is no software timer
  expiration to  handle, no software timer will be dequeued and the next
  software timer expiration date will be reused to reprogram the
  hardware timer.

 > 
 > The question about recursion remains:
 > If a domain decides in its timer interrupt handler to reprogram
 > the timer by calling __ipipe_mach_set_dec() (indirectly), and
 > we already are too close to the next match, then that interrupt
 > handler is called recursively.
 > Is every ipipe domain expected to cope with this?

As explained above, this recursion can only happen for a limited time
(in the worst case, if nkschedlat is 0, during 8 hardware timer ticks).
Keep in mind that these functions are called with interrupts off, so the
"recursion", is serialized.

You should really have a look at ksrc/nucleus/timer.c, functions
do_tick_aperiodic and do_tick_periodic. 

-- 


					    Gilles Chanteperdrix.

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

[Detlef Vollmann]

Gilles Chanteperdrix wrote:
> Detlef Vollmann wrote:

>  > I'll just add another test after the update of OSMR0 for the
>  > case that we got interrupted between the comparison and the
>  > assignment.  And in that (probably very rare) case I accept that
>  > I loose a timer tick :-(
> 
> I do not see what you mean.
Sorry, I didn't see that the code is running under IRQ-lock.

> "delay" value does not change over time.
Well, ipipe_tune_timer() is in the public interface of ipipe,
so it might be used for all kind of things...

> 
>  >
>  > Also, this way the timer comes a bit early, so any handler that
>  > checks the TSC might think that this is the wrong interrupt --
>  > and wait forever for the correct one.
>  > But the only other option would be the busy wait...
> 
> It will work for Xenomai:
> - in periodic mode, each interrupt is treated as a tick
> - in aperiodic mode, there are two guards; first the tsc is compared to
>   the next software timer expiration date using nkschedlat as a margin;
>   second, if the tick is so early that there is no software timer
>   expiration to  handle, no software timer will be dequeued and the next
>   software timer expiration date will be reused to reprogram the
>   hardware timer.
Ok, so the busy wait would be in the loop between do_tick_aperiodic
and __ipipe_mach_set_dec: the next expiration date is not yet
reached, but it is to close to do the update.

> As explained above, this recursion can only happen for a limited time
> (in the worst case, if nkschedlat is 0, during 8 hardware timer ticks).
> Keep in mind that these functions are called with interrupts off, so the
> "recursion", is serialized.
Ok, understood.  Thanks for the detailed explanation.

> You should really have a look at ksrc/nucleus/timer.c, functions
> do_tick_aperiodic and do_tick_periodic.
Thanks for the pointer.

And I think you're correct, for Xenomai it will work.
Unfortunately I'm trying to do a general ipipe port for PXA.
I'm doing this for a polytech who wants to use this with their
students, and so they probably want to use it with other domain
on top of ipipe (rtai 3.3, Siemens' implementation of the Posix
RT interface, and maybe even an own domain for experimenting).

But probably all aperiodic timers need such a scheme, so I'll
not busy loop for now.

Thanks again for your explanation
 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/

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Detlef Vollmann wrote:
> ...
> And I think you're correct, for Xenomai it will work.
> Unfortunately I'm trying to do a general ipipe port for PXA.
> I'm doing this for a polytech who wants to use this with their
> students, and so they probably want to use it with other domain
> on top of ipipe (rtai 3.3, Siemens' implementation of the Posix
> RT interface, and maybe even an own domain for experimenting).

I think the problem is not that some interface is "public". The point is
rather that inherent characteristics like "always called with interrupts
off" or "has to be protected with ipipe_critical" are not yet
documented. Adding such comments to your work might be a start. The same
applies to how a domain can expect soon-to-expire timer events are handled.

Creating a generic patch without basing it on Xenomai-specific
assumption is a reasonable approach, for sure. Nevertheless, the first
non-Xenomai user you mentioned requires more patching and far more
cleanup/update of its core to work over ARM again. And the second one is
unfortunately still unpublished.

The third scenario is quite real. Example: I have an experimental patch
for the new irqbench pending that demonstrates how to lift simple IRQ
jobs over Xenomai in its own domain. Gives nice worst-case IRQ latencies
even on low-end, even under heavy Linux *and* Xenomai load (the latter
ATM only with a small patch against ipipe to enable preemptible IRQ
handlers for all non-heading domains, not only the root one).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]