[Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Sebastian Smolorz]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Hi,

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?

--
Sebastian

[-- Attachment #2: ipipe-2.6.15-arm-1.5-02_release_timer.patch --]
[-- Type: text/x-diff, Size: 2537 bytes --]

diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-integrator/core.c linux-2.6.15-ipipe.work/arch/arm/mach-integrator/core.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-integrator/core.c	2006-11-08 16:44:02.000000000 +0100
+++ linux-2.6.15-ipipe.work/arch/arm/mach-integrator/core.c	2006-11-13 12:07:21.000000000 +0100
@@ -330,6 +330,12 @@ void __ipipe_mach_set_dec(unsigned long 
 }
 EXPORT_SYMBOL(__ipipe_mach_set_dec);
 
+void __ipipe_mach_release_timer(void)
+{
+	__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
+}
+EXPORT_SYMBOL(__ipipe_mach_release_timer);
+
 unsigned long __ipipe_mach_get_dec(void)
 {
 	return readl(TIMER1_VA_BASE + TIMER_VALUE);
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-pxa/time.c linux-2.6.15-ipipe.work/arch/arm/mach-pxa/time.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-pxa/time.c	2006-11-08 16:44:02.000000000 +0100
+++ linux-2.6.15-ipipe.work/arch/arm/mach-pxa/time.c	2006-11-13 12:11:11.000000000 +0100
@@ -324,6 +324,12 @@ void __ipipe_mach_set_dec(unsigned long 
 }
 EXPORT_SYMBOL(__ipipe_mach_set_dec);
 
+void __ipipe_mach_release_timer(void)
+{
+	__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
+}
+EXPORT_SYMBOL(__ipipe_mach_release_timer);
+
 unsigned long __ipipe_mach_get_dec(void)
 {
 	return OSMR0 - OSCR;
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-sa1100/time.c linux-2.6.15-ipipe.work/arch/arm/mach-sa1100/time.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-sa1100/time.c	2006-11-08 16:44:02.000000000 +0100
+++ linux-2.6.15-ipipe.work/arch/arm/mach-sa1100/time.c	2006-11-13 12:07:26.000000000 +0100
@@ -314,6 +314,12 @@ void __ipipe_mach_set_dec(unsigned long 
 }
 EXPORT_SYMBOL(__ipipe_mach_set_dec);
 
+void __ipipe_mach_release_timer(void)
+{
+	__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
+}
+EXPORT_SYMBOL(__ipipe_mach_release_timer);
+
 unsigned long __ipipe_mach_get_dec(void)
 {
 	return OSMR0 - OSCR;
diff -upr linux-2.6.15-ipipe.orig/include/asm-arm/ipipe.h linux-2.6.15-ipipe.work/include/asm-arm/ipipe.h
--- linux-2.6.15-ipipe.orig/include/asm-arm/ipipe.h	2006-11-13 11:39:03.000000000 +0100
+++ linux-2.6.15-ipipe.work/include/asm-arm/ipipe.h	2006-11-13 12:34:55.000000000 +0100
@@ -117,6 +117,7 @@ extern unsigned int __ipipe_mach_ticks_p
 extern void __ipipe_mach_acktimer(void);
 extern unsigned long long __ipipe_mach_get_tsc(void);
 extern void __ipipe_mach_set_dec(unsigned long);
+extern void __ipipe_mach_release_timer(void);
 extern unsigned long __ipipe_mach_get_dec(void);
 extern void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs);
 

[-- Attachment #3: xeno_release_timer.patch --]
[-- Type: text/x-diff, Size: 404 bytes --]

Index: ksrc/arch/arm/hal.c
===================================================================
--- ksrc/arch/arm/hal.c	(Revision 1834)
+++ ksrc/arch/arm/hal.c	(Arbeitskopie)
@@ -94,7 +94,7 @@
     if (rthal_periodic_p)
         rthal_reset_timer();
     else
-        __ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
+        __ipipe_mach_release_timer();
 
     rthal_irq_release(RTHAL_TIMER_IRQ);
 

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Gilles Chanteperdrix]

Sebastian Smolorz wrote:
> Hi,
> 
> 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 ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Sebastian Smolorz]

Gilles Chanteperdrix wrote:
> Sebastian Smolorz wrote:
> > Hi,
> >
> > 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.

--
Sebastian

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Gilles Chanteperdrix]

Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
> 
>>Sebastian Smolorz wrote:
>>
>>>Hi,
>>>
>>>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

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Sebastian Smolorz]

Gilles Chanteperdrix wrote:
> Sebastian Smolorz wrote:
> > Gilles Chanteperdrix wrote:
> >>Sebastian Smolorz wrote:
> >>>Hi,
> >>>
> >>>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.

Unfortunately, this solution is not applicable. The timers of PXA and SA are 
counting up whereas the S3C24xx timers are counting down to zero. There is no 
match register for the next interrupt. In contrast, the timer must be 
programmed with the new dec value directly, thus stopping it for the time of 
re-programming.

--
Sebastian

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Gilles Chanteperdrix]

Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
>>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.
> 
> 
> Unfortunately, this solution is not applicable. The timers of PXA and SA are 
> counting up whereas the S3C24xx timers are counting down to zero. There is no 
> match register for the next interrupt. In contrast, the timer must be 
> programmed with the new dec value directly, thus stopping it for the time of 
> re-programming.

Right, you are in the same case as the integrator platform.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly

[Sebastian Smolorz]

Gilles Chanteperdrix wrote:
> Sebastian Smolorz wrote:
> > Gilles Chanteperdrix wrote:
> >>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.
> >
> > Unfortunately, this solution is not applicable. The timers of PXA and SA
> > are counting up whereas the S3C24xx timers are counting down to zero.
> > There is no match register for the next interrupt. In contrast, the timer
> > must be programmed with the new dec value directly, thus stopping it for
> > the time of re-programming.
>
> Right, you are in the same case as the integrator platform.

Yes. But I cannot adopt the integrator's re-programming of the timer in the 
Linux timer interrupt handler because this would lead to lost ticks or rather 
to longer periods. Therefore I proposed the patch.

--
Sebastian