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
[Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
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. :-) 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. Sebastian [1] https://mail.gna.org/public/xenomai-core/2006-10/msg00079.html [2] https://mail.gna.org/public/xenomai-core/2006-09/msg00055.html # ./latency == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... BUG: soft lockup detected on CPU#0! Pid: 772, comm: dd CPU: 0 PC is at __ipipe_mach_get_tsc+0x44/0x54 LR is at 0x0 pc : []lr : [<>]Not tainted sp : ip : fp : r10: r9 : r8 : r7 : r6 : r5 : r4 : r3 : r2 : r1 : r0 : Flags: nZcv IRQs on FIQs on Mode USER_32 Segment user Control: C000317F Table: 31FF DAC: 0015 [] (show_regs+0x0/0x4c) from [] (softlockup_tick+0x64/0x7c) r4 = C027F424 [] (softlockup_tick+0x0/0x7c) from [] (do_timer+0x3e8/0x468) r4 = C02A265C [] (do_timer+0x0/0x468) from [] (timer_tick+0xb4/0xe4) [] (timer_tick+0x0/0xe4) from [] (s3c2410_timer_interrupt+0x78/0xa4) r6 = C02A1610 r5 = r4 = C022A4C8 [] (s3c2410_timer_interrupt+0x0/0xa4) from [] (__do_irq+0x40/0x74) r8 = C027F424 r7 = 001E r6 = r5 = r4 = C022A4C8 [] (__do_irq+0x0/0x74) from [] (do_edge_IRQ+0xa0/0xfc) r8 = C027F424 r7 = C027F424 r6 = C022A4C8 r5 = 001E r4 = C027E3A0 [] (do_edge_IRQ+0x0/0xfc) from [] (asm_do_IRQ+0x50/0x13c) r7 = C022DFC0 r6 = 001E r5 = r4 = C022DFC8 [] (asm_do_IRQ+0x0/0x13c) from [] (__ipipe_sync_stage+0x1e0/0x268) [] (__ipipe_sync_stage+0x0/0x268) from [] (__ipipe_walk_pipeline+0x98/0xbc) [] (__ipipe_walk_pipeline+0x0/0xbc) from [] (__ipipe_handle_irq+0x1a4/0x1b4) r7 = C02A3B00 r6 = 001E r5 = 001E r4 = [] (__ipipe_handle_irq+0x0/0x1b4) from [] (__ipipe_grab_irq+0xc4/0x110) [] (__ipipe_grab_irq+0x0/0x110) from [] (__irq_usr+0x40/0x170) ___ 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
[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.
Sebastian
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/irq.c linux-2.6.15-ipipe/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/arch/arm/mach-s3c2410/irq.c 2006-10-18 15:17:25.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/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/arch/arm/mach-s3c2410/s3c2440-irq.c 2006-10-12 09:41:30.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
@@ -19,8 +21,10 @@
*
* Changelog:
* 25-Jul-2005 BJD Split from irq.c
+ * 11-Oct-2006 Sebastian Smolorz
+ * Added Adeos/Ipipe support
*
-*/
+ */
#include
#include
@@ -28,6 +
