On 05/14/2012 06:18 PM, Gilles Chanteperdrix wrote:
> On 05/14/2012 06:13 PM, aubin.rebil...@free.fr wrote:
>> Hi Gilles,
>>
>> I've followed your advices and reimplemented the timer management.
>> Now it's an up counter wrapping to 0 on overflow, it uses a match
>> register to trigger the interrupt and it's never disabled.
>>
>> I've also cleaned the code : suppressed linux specific calls, move
>> update_tsc to linux handler, etc... as you advised me.
>>
>> Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI
>> disabled, and it's working fine.
>> I also tested with only CONFIG_XENOMAI disabled and it's still
>> working as expected.
>>
>> Nevertheless, the issue is still the same. It hangs after starting
>> the init program.
>>
>> After investigations, the problem is that __ipipe__mach_set_dec is
>> never called after Xenomai has taken control of the timer. The last
>> timer update was done in rthal_timer_calibrate and it effectively
>> triggers an interrupt after MAXINT ticks (I've put a printk in the
>> linux timer handler and it's displayed after a few time).
>>
>> My problem is that i don't really understand the timer management by
>> Xenomai. As i understood each skin has its own timers and Xenomai
>> manages to trigger them when expected. But what code is managing the
>> linux timer ?
>> I'm expecting to probably have errors in my ipipe code that's why i'm
>> asking this, to follow the execution and see where it is broken.
>>
>> Thank you very much,
>
>
> If the interrupt triggers only once, it probably means that the timer
> needs some acknowledgement that must be put in __ipipe_mach_acktimer.
>
> The code managing Linux timer works and has been validated on all the
> port so far. So, the thing probably at fault is the timer management
> code in the I-pipe patch. Do not worry for Linux timer interrupt, only
> take care of ipipe_mach_set_dec and ipipe_mach_acktimer.
>
> Also, if some timer programming is done in linux timer interrupt, it
> should not be done once ipipe_mach_timerstolen is true.
>
To summarize, there are two states in the system:
Either Linux is handling the timer, in which case:
- ipipe_mach_timerstolen == 0
- ipipe_mach_acktimer is called to acknowledge the linux timer interrupt
- linux timer interrupt routine is called for each timer interrupt, HZ
times a second, and in charge to reprogram the timer hardware if it
needs to be reprogrammed
Either xenomai is handling the timer, in which case:
- ipipe_mach_timerstolen == 1
- ipipe_mach_acktimer is called to acknowledge the xenomai timer interrupt
- ipipe_mach_set_dec is called by xenomai to program the next timer
interrupt
linux timer interrupt is called HZ times a second, but should not touch
anything related to the timer hardware, because that part is handled by
xenomai now (vie ipipe_mach_set_dec).
if CONFIG_IPIPE is enabled and CONFIG_XENOMI is disabled, only the first
state happens.
if CONFIG_XENOMAI is enabled, as soon as xenomai is started, we enter
the second state.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
