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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to