Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
>>Sebastian Smolorz wrote:
>>>here's a proposal for a minor change in the I-pipe implementation for
>>>ARM. Since it is required for my S3C24xx patch not to call
>>>__ipipe_mach_set_dec directly when the timer is released by the Xenomai
>>>domain I suggest the following changes. The patch comprises the necessary
>>>modifications for PXA, SA1100 and Integrator, too.
>>>Comments or objections?
>>Why can not you call __ipipe_mach_set_dec directly when the timer is
>>released ?
> The timer used for generating interrupts operates in auto-reloading mode when 
> it is under Linux control. But when Xenomai reloads the timer the mode of 
> operation is one-shot (auto-reload feature in hardware is off). So I have to 
> make a distinction between setting the dec value by Xenomai for programming 
> the next period and setting the dec value to __ipipe_mach_ticks_per_jiffy 
> when the timer control is given back to Linux.
> The reason for this is the fact that programming a timer on the S3C24xx can 
> take some ticks which means that these ticks aren't count whereas time is 
> going on in the real world. So it is more reasonable to let the timer reload 
> itself when Xenomai hasn't started it. Setting __ipipe_mach_ticks_per_jiffy 
> in the Linux interrupt handler would make every period last some ticks 
> longer.

You can avoid this problem by adding LATCH or
__ipipe_mach_ticks_per_jiffy to the current value of the match register
in the timer interrupt, as it is done for the SA and PXA architectures.

                                                 Gilles Chanteperdrix

Xenomai-core mailing list

Reply via email to