Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Am Freitag, 10. November 2006 11:14 schrieb Gilles Chanteperdrix: > Sebastian Smolorz wrote: > > Hi all, > > > > now that the teething problems of my I-pipe port to the S3C24xx are cured > > (hopefully ...) I'm going to iterate it to v4. We've established a > > project homepage for that port > > http://opensource.emlix.com/ipipe-s3c24xx/ > > What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? OK, this is not correct. I will fix it to #define __ipipe_irqbit(irq) (1 << ((irq) - S3C2410_CPUIRQ_OFFSET)) as you suggested originally. Thanks, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: Hi all, now that the teething problems of my I-pipe port to the S3C24xx are cured (hopefully ...) I'm going to iterate it to v4. We've established a project homepage for that port http://opensource.emlix.com/ipipe-s3c24xx/ What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: > Jan Kiszka wrote: >> Sebastian Smolorz wrote: >>> However, there is one disturbing issue. When I execute >>> >>> dd if=/dev/zero of=/dev/null >>> >>> and the latency test in userspace with a period not less than 150 us the >>> worst case latency is about 220 us. But when I start latency with -p 100 >>> I get a softlock like the one attached. I guess this is the same problem >>> as Detlef Vollmann described in [2]. So I think it's time for a big fat >>> ARM-specific warning in the troubleshooting file and perhaps a >>> modification of the testsuite so that if being compiled for ARM the >>> default sample periods are greater than the 100 us now. >> Something is preventing the watchdog kthread from being executed for >> more than 10 s. Maybe this is just a sign that the systems is hopelessly >> overloaded (what are average latencies?). > > They are 120-130 us. Which is a good sign that the board is basically only flushing caches when running the test at this frequency. Still the question remains if the BUG is an expectable behaviour or a sign for hidden problems. > >> Maybe it is a real IRQ or >> scheduling issue in Linux caused by I-pipe. Maybe it is time to port the >> I-pipe tracer... ;) > > With the latest Adeos upgrade for ARM the I-pipe tracer was integrated, > wasn't > it? I was already taking its usage into account. The arch-independent code is merged for ARM, but it still takes to port ipipe-mcount.S and likely ipipe_read_tsc + related services. Not much to do, though. Take a look at the code in PREEMPT_RT for the mcount part. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > However, there is one disturbing issue. When I execute > > > > dd if=/dev/zero of=/dev/null > > > > and the latency test in userspace with a period not less than 150 us the > > worst case latency is about 220 us. But when I start latency with -p 100 > > I get a softlock like the one attached. I guess this is the same problem > > as Detlef Vollmann described in [2]. So I think it's time for a big fat > > ARM-specific warning in the troubleshooting file and perhaps a > > modification of the testsuite so that if being compiled for ARM the > > default sample periods are greater than the 100 us now. > > Something is preventing the watchdog kthread from being executed for > more than 10 s. Maybe this is just a sign that the systems is hopelessly > overloaded (what are average latencies?). They are 120-130 us. > Maybe it is a real IRQ or > scheduling issue in Linux caused by I-pipe. Maybe it is time to port the > I-pipe tracer... ;) With the latest Adeos upgrade for ARM the I-pipe tracer was integrated, wasn't it? I was already taking its usage into account. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: > Hi all, > > now that the teething problems of my I-pipe port to the S3C24xx are cured > (hopefully ...) I'm going to iterate it to v4. We've established a project > homepage for that port > http://opensource.emlix.com/ipipe-s3c24xx/ > in order to concentrate the source code and information at one point. > Probably > tomorrow I will come up with a patch in order to address point 2 in my email > from 27.10.2006 ([1]). After that I can go to v5 of my patch and beg for > integration. :-) Nice to hear. > > However, there is one disturbing issue. When I execute > > dd if=/dev/zero of=/dev/null > > and the latency test in userspace with a period not less than 150 us the > worst > case latency is about 220 us. But when I start latency with -p 100 I get a > softlock like the one attached. I guess this is the same problem as Detlef > Vollmann described in [2]. So I think it's time for a big fat ARM-specific > warning in the troubleshooting file and perhaps a modification of the > testsuite so that if being compiled for ARM the default sample periods are > greater than the 100 us now. Something is preventing the watchdog kthread from being executed for more than 10 s. Maybe this is just a sign that the systems is hopelessly overloaded (what are average latencies?). Maybe it is a real IRQ or scheduling issue in Linux caused by I-pipe. Maybe it is time to port the I-pipe tracer... ;) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: > > Sebastian Smolorz wrote: > >> Hi, > >> > >> here comes version 2 of the I-pipe patch for the S3C24xx ARM. The > >> reported problem is solved, the timer works as expected as far as I > >> can see. Linux is still there after insmod'ding the native skin. More > >> test results will follow next week after I tortured the new patch with > >> the whole testsuite arsenal. ;-) > >> > >> The patch has got two suboptimal characteristics due to the generic > >> ARM I-pipe implementation which I did not want to change during the > >> first steps: > >> > >> 1. Regarding the demux of chained IRQs (See [1]). As the S3C24xx has > >> more than one chained IRQ there are two consecutive queries for them > >> in __ipipe_mach_irq_mux_p() and __ipipe_mach_demux_irq(). This could > >> be optimized. > > > > You should use switch/case instead of if else if else if, the generated > > code would be better optimized. > > You can make the test cheap test by using a mask. Yes, I will do it that way. Thanks! Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
Gilles Chanteperdrix wrote: Sebastian Smolorz wrote: Hi, here comes version 2 of the I-pipe patch for the S3C24xx ARM. The reported problem is solved, the timer works as expected as far as I can see. Linux is still there after insmod'ding the native skin. More test results will follow next week after I tortured the new patch with the whole testsuite arsenal. ;-) The patch has got two suboptimal characteristics due to the generic ARM I-pipe implementation which I did not want to change during the first steps: 1. Regarding the demux of chained IRQs (See [1]). As the S3C24xx has more than one chained IRQ there are two consecutive queries for them in __ipipe_mach_irq_mux_p() and __ipipe_mach_demux_irq(). This could be optimized. You should use switch/case instead of if else if else if, the generated code would be better optimized. You can make the test cheap test by using a mask. #define __ipipe_irqbit(irq) (1 << ((irq) - S3C2410_CPUIRQ_OFFSET)) #ifdef CONFIG_CPU_S3C2440 #define __ipipe_muxed_irqmask (__ipipe_irqbit(IRQ_UART0) \ | __ipipe_irqbit(IRQ_UART1) \ | __ipipe_irqbit(IRQ_UART2) \ | __ipipe_irqbit(IRQ_ADCPARENT) \ | __ipipe_irqbit(IRQ_WDT) \ | __ipipe_irqbit(IRQ_CAM)) #else /* !CONFIG_CPU_S3C2440 */ #define __ipipe_muxed_irqmask (__ipipe_irqbit(IRQ_UART0) \ | __ipipe_irqbit(IRQ_UART1) \ | __ipipe_irqbit(IRQ_UART2) \ | __ipipe_irqbit(IRQ_ADCPARENT)) #endif /* CONFIG_CPU_S3C2440 */ #define __ipipe_mach_irq_mux_p(irq) \ ((irq) <= IRQ_ADCPARENT \ && (__ipipe_irqbit(irq) & __ipipe_muxed_irqmask(irq))) -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
Sebastian Smolorz wrote: Hi, here comes version 2 of the I-pipe patch for the S3C24xx ARM. The reported problem is solved, the timer works as expected as far as I can see. Linux is still there after insmod'ding the native skin. More test results will follow next week after I tortured the new patch with the whole testsuite arsenal. ;-) The patch has got two suboptimal characteristics due to the generic ARM I-pipe implementation which I did not want to change during the first steps: 1. Regarding the demux of chained IRQs (See [1]). As the S3C24xx has more than one chained IRQ there are two consecutive queries for them in __ipipe_mach_irq_mux_p() and __ipipe_mach_demux_irq(). This could be optimized. You should use switch/case instead of if else if else if, the generated code would be better optimized. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
Hi,
here comes version 2 of the I-pipe patch for the S3C24xx ARM. The reported
problem is solved, the timer works as expected as far as I can see. Linux is
still there after insmod'ding the native skin. More test results will follow
next week after I tortured the new patch with the whole testsuite
arsenal. ;-)
The patch has got two suboptimal characteristics due to the generic ARM I-pipe
implementation which I did not want to change during the first steps:
1. Regarding the demux of chained IRQs (See [1]). As the S3C24xx has more than
one chained IRQ there are two consecutive queries for them in
__ipipe_mach_irq_mux_p() and __ipipe_mach_demux_irq(). This could be
optimized.
2. If the xenomai timer is stopped the first two jiffies for Linux are one
timer tick too long. The solution could be a change of this line [2]. The
patch for the S3C24xx needs a timer reload value of
__ipipe_mach_ticks_per_jiffy-1 when Xenomai's timer is inactive. For example
we could introduce a new inline function which is called in line 98 of hal.c.
The new I-pipe patch would then call
__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy-1) and the other ARM
patches __ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy).
Sebastian
[1]
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/arch/arm/patches/adeos-ipipe-2.6.15-arm-1.5-01.patch?v=SVN-trunk;a=arm#L3761
[2]
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/arch/arm/hal.c?v=SVN-trunk;a=arm#L98
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/irq.c linux-2.6.15-ipipe.work/arch/arm/mach-s3c2410/irq.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/irq.c 2006-10-10 16:36:50.0 +0200
+++ linux-2.6.15-ipipe.work/arch/arm/mach-s3c2410/irq.c 2006-10-26 11:55:45.0 +0200
@@ -3,6 +3,8 @@
* Copyright (c) 2003,2004 Simtec Electronics
* Ben Dooks <[EMAIL PROTECTED]>
*
+ * Copyright (C) 2006 Sebastian Smolorz <[EMAIL PROTECTED]>, emlix GmbH
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -48,7 +50,10 @@
*
* 25-Jul-2005 Ben Dooks
* Split the S3C2440 IRQ code to seperate file
-*/
+ *
+ * 11-Oct-2006 Sebastian Smolorz
+ * Added Adeos/Ipipe support
+ */
#include
#include
@@ -56,6 +61,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +76,14 @@
#include "pm.h"
#include "irq.h"
+#ifdef CONFIG_IPIPE
+#ifdef CONFIG_CPU_S3C2440
+extern void __ipipe_s3c_irq_demux_wdtac97(unsigned int irq,
+ struct pt_regs *regs);
+extern void __ipipe_s3c_irq_demux_cam(unsigned int irq, struct pt_regs *regs);
+#endif /* CONFIG_CPU_S3C2440 */
+#endif /* CONFIG_IPIPE */
+
/* wakeup irq control */
#ifdef CONFIG_PM
@@ -573,6 +587,71 @@ s3c_irq_demux_uart2(unsigned int irq,
}
+#ifdef CONFIG_IPIPE
+static void __ipipe_s3c_irq_demux_uart(unsigned int start,
+ unsigned int subsrc,
+ struct pt_regs *regs)
+{
+ unsigned int offset = start - IRQ_S3CUART_RX0;
+
+ subsrc >>= offset;
+ subsrc &= 7;
+
+ if (subsrc != 0) {
+ if (subsrc & 1)
+ __ipipe_handle_irq(start, regs);
+ if (subsrc & 2)
+ __ipipe_handle_irq(start+1, regs);
+ if (subsrc & 4)
+ __ipipe_handle_irq(start+2, regs);
+ }
+}
+
+static void __ipipe_s3c_irq_demux_adc(unsigned int subsrc,
+ struct pt_regs *regs)
+{
+ subsrc >>= 9;
+ subsrc &= 3;
+
+ if (subsrc != 0) {
+ if (subsrc & 1)
+ __ipipe_handle_irq(IRQ_TC, regs);
+ if (subsrc & 2)
+ __ipipe_handle_irq(IRQ_ADC, regs);
+ }
+}
+
+void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
+{
+ unsigned int subsrc, submsk;
+ struct irqdesc *desc_unused = irq_desc + irq;
+
+ /* read the current pending interrupts, and the mask
+ * for what it is available */
+ subsrc = __raw_readl(S3C2410_SUBSRCPND);
+ submsk = __raw_readl(S3C2410_INTSUBMSK);
+
+ subsrc &= ~submsk;
+
+ if (irq == IRQ_UART0)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX0, subsrc, regs);
+ else if (irq == IRQ_UART1)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX1, subsrc, regs);
+ else if (irq == IRQ_UART2)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX2, subsrc, regs);
+ else if (irq == IRQ_ADCPARENT)
+ __ipipe_s3c_irq_demux_adc(subsrc, regs);
+#ifdef CONFIG_CPU_S3C2440
+ else if (irq == IRQ_WDT)
+ __ipipe_s3c_irq_demux_wdtac97(subsrc, regs);
+ else if (irq == IRQ_CAM)
+ __ipipe_s3c_irq_demux_cam(subsrc, regs);
+#endif /* CONFIG_CPU_S3C2440 */
+
+ desc_unused->chip->unmask(irq);
+}
+#endif /* CONFIG_IPIPE */
+
/* s3c24xx_init_irq
*
* Initialise S3C2410 IRQ system
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/s3c2440-irq.c linux-2.6.15-ipipe.work/arch/arm/mach-s3c2410/s3c2440-irq.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/s3c2440-irq.c 2006-10-10 16:36:50.0 +0200
+++ linux-2.6.15-ipipe.work/arch/arm/mach-s3c2410/s3c2440-irq.c 2006-10-26 11:55:45.0 +0200
@@ -3,6 +3,8 @@
* Copyright (c)
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
> Hi all, > > I'm currently working on porting I-pipe to the ARM S3C24xx. The patch is > attached, it must be applied after the shipped > adeos-ipipe-2.6.15-arm-1.5-01.patch. Unfortunately, there is still a severe > bug somewhere. I built Xenomai as modules. When I try to modprobe > xeno_native, the system hangs. No reaction at all, inlcuding serial console > and network access. I guess that interrupts are not handled any more. From > what I see if I spread some debug printk() into my code, the timer starts > working under the control of the Xenomai domain and one or two calls to the > Linux timer interrupt handler are made. But after that nothing happens any > more. > > As I try to find the bug for some days now but wasn't successful maybe the > experts have any hints where to continue searching. Or perhaps there is > someone who can test it and confirm or disprove my observation? It would be > great to support one more ARM model. Small update with new infos: After Xenomai has (re)started the system timer the Linux timer interrupt handler ist called only once, but xnintr_clock_handler() is called several thousand times. So it seems that the timer interrupt handler of Linux is not properly called or Xenomai is starving Linux. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
