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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]