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"?



Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to