Stelian Pop wrote:
> If you have specific questions feel free to ask. But I suggest you read
> and try to understand the code first.
Maybe we could provide a quick overview of how this works, Stelian,
please correct me if I am wrong.
If we start before rthal_timer_request is called, when the timer is
handled by Linux, we see that __ipipe_decr_ticks is set to
__ipipe_mach_ticks_per_jiffy, so that __ipipe_grab_irq does not
reprogram the timer. But __ipipe_mach_timerstolen is set to 0, so
integrator_timer_interrupt reprogram the timer at each tick.
Now, when rthal_timer_request (defined in ksrc/arch/arm/hal.c) is
called when Xenomai start handling the timer, we can see the two
different modes:
- in periodic mode, ipipe_tune_timer get called (indirectly via
rthal_set_timer, defined in include/asm-generic/hal.h), so
the proper value of __ipipe_decr_ticks is computed using
__ipipe_mach_ticks_per_jiffy, and __ipipe_mach_set_dec get called by
__ipipe_grab_irq at each tick to reprogram the timer
- in aperiodic (aka one-shot) mode, ipipe_tune_timer does not get
called, so __ipipe_decr_ticks remains set to
__ipipe_mach_ticks_per_jiffy and __ipipe_grab_irq does not call
__ipipe_mach_set_dec. Instead, __ipipe_mach_set_dec is called for
each shot by Xenomai (function rthal_timer_program_shot in
include/asm-arm/hal.h)
In both modes, __ipipe_mach_timerstolen is set to 1, so that
integrator_timer_interrupt never reprograms the timer.
When CONFIG_IPIPE is set, integrator_timer_interrupt never acks the
timer interrupt, instead, it gets ack'ed and unmasked in
__ipipe_ack_timerirq, installed as an acknowledge function for the timer
IRQ in __ipipe_enable_pipeline.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
