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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
