Re: [Xenomai-core] Missing IRQ end function on PowerPC
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is
more obvious. On non-PPC archs it would translate to *_irq_enable.
I realized, that *_irq_enable is used in various place/skins and
therefore I have not yet provided a patch.
The function xnarch_irq_enable seems to be called in only two functions,
xintr_enable and xnintr_irq_handler when the flag XN_ISR_ENABLE is set.
In any case, since I am not sure if this has to be done at the Adeos
level or in Xenomai, we will wait for Philippe to come back and decide.
Attached is a temporary Xenomai patch fixing the IRQ end problem for the
PowerPC arch. I had a closer look to the various IRQ end functions on
PowerPC:
Applied and generalized for all archs, thanks.
ic_end(unsigned int irq)
{
ic_ack(irq);
if (!(irq_desc[irq].status (IRQ_DISABLED | IRQ_INPROGRESS))) {
ic_enable(irq);
}
}
In most cases the end functions do the same than the begin functions but
there are exceptions where the end functions do an additional ic_ack()
as shown above.
Wolfgang.
+ diff -u xenomai/include/asm-generic/hal.h.IRQEND
xenomai/include/asm-generic/hal.h
--- xenomai/include/asm-generic/hal.h.IRQEND2006-01-11 18:03:34.0
+0100
+++ xenomai/include/asm-generic/hal.h 2006-01-19 20:52:40.0 +0100
@@ -357,6 +357,8 @@
int rthal_irq_disable(unsigned irq);
+int rthal_irq_end(unsigned irq);
+
int rthal_irq_host_request(unsigned irq,
irqreturn_t (*handler)(int irq,
void *dev_id,
+ diff -u xenomai/include/asm-generic/system.h.IRQEND
xenomai/include/asm-generic/system.h
--- xenomai/include/asm-generic/system.h.IRQEND 2006-01-11 18:03:34.0
+0100
+++ xenomai/include/asm-generic/system.h2006-01-19 20:50:17.0
+0100
@@ -496,6 +496,12 @@
return rthal_irq_disable(irq);
}
+static inline int xnarch_end_irq (unsigned irq)
+
+{
+ return rthal_irq_end(irq);
+}
+
static inline void xnarch_chain_irq (unsigned irq)
{
+ diff -u xenomai/include/asm-uvm/system.h.IRQEND
xenomai/include/asm-uvm/system.h
--- xenomai/include/asm-uvm/system.h.IRQEND 2006-01-11 18:03:34.0
+0100
+++ xenomai/include/asm-uvm/system.h2006-01-19 20:51:36.0 +0100
@@ -296,6 +296,13 @@
return -ENOSYS;
}
+static inline int xnarch_end_irq (unsigned irq)
+
+{
+return -ENOSYS;
+}
+
+
static inline void xnarch_chain_irq (unsigned irq)
{ /* Nop */ }
+ diff -u xenomai/ksrc/arch/generic/hal.c.IRQEND xenomai/ksrc/arch/generic/hal.c
--- xenomai/ksrc/arch/generic/hal.c.IRQEND 2006-01-11 18:03:42.0
+0100
+++ xenomai/ksrc/arch/generic/hal.c 2006-01-19 20:54:06.0 +0100
@@ -1156,6 +1156,7 @@
EXPORT_SYMBOL(rthal_irq_release);
EXPORT_SYMBOL(rthal_irq_enable);
EXPORT_SYMBOL(rthal_irq_disable);
+EXPORT_SYMBOL(rthal_irq_end);
EXPORT_SYMBOL(rthal_irq_host_request);
EXPORT_SYMBOL(rthal_irq_host_release);
EXPORT_SYMBOL(rthal_irq_host_pend);
+ diff -u xenomai/ksrc/arch/powerpc/hal.c.IRQEND xenomai/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c.IRQEND 2006-01-11 18:03:41.0
+0100
+++ xenomai/ksrc/arch/powerpc/hal.c 2006-01-19 21:56:19.0 +0100
@@ -356,6 +356,27 @@
return 0;
}
+int rthal_irq_end (unsigned irq)
+
+{
+if (irq = IPIPE_NR_XIRQS)
+ return -EINVAL;
+
+if (rthal_irq_descp(irq)-handler != NULL)
+{
+ if (rthal_irq_descp(irq)-handler-end != NULL)
+ rthal_irq_descp(irq)-handler-end(irq);
+ else if (rthal_irq_descp(irq)-handler-enable != NULL)
+ rthal_irq_descp(irq)-handler-enable(irq);
+ else
+ return -ENODEV;
+ }
+else
+ return -ENODEV;
+
+return 0;
+}
+
static inline int do_exception_event (unsigned event, unsigned domid, void
*data)
{
+ diff -u xenomai/ksrc/nucleus/intr.c.IRQEND xenomai/ksrc/nucleus/intr.c
--- xenomai/ksrc/nucleus/intr.c.IRQEND 2006-01-11 18:03:42.0 +0100
+++ xenomai/ksrc/nucleus/intr.c 2006-01-19 20:42:53.0 +0100
@@ -363,7 +363,7 @@
++intr-hits;
if (s XN_ISR_ENABLE)
- xnarch_enable_irq(irq);
+ xnarch_end_irq(irq);
if (s XN_ISR_CHAINED)
xnarch_chain_irq(irq);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)
Dmitry Adamushko wrote: Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the name field to the interrupt object of the nucleus layer. Reworks the related bits of the native skin (+ a few minor changes for posix and rtdm) to support the named interrupt objects. 2) shirq-v7.patch Generic support for shared interrupts. 3) shirq-proc.patch /proc support. Now /proc/xenomai/irq shows the names of handlers. The related code have been removed from the hal layer to nucleus. - 4) shirq-isa.patch Trying to handle the edge-triggered stuff. This is a very preliminary version so the only thing I promise so far is that it compiles successfully. Why not name it XN_ISR_EDGE or so (also the related functions etc.)? Although it mostly targets ISA hardware, it's about the edge-triggered characteristic of that devices after all. The functionality added by first 3 patches seem to be working. -- Best regards, Dmitry Adamushko I'm now trying to organise a full test scenario with shared UART ISA-IRQs at our institute. May take till beginning of next week, some regressions in our own software need to be fixed first. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (base, /proc support, edge-triggered stuff)
On 02/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the name field to the interrupt object of the nucleus layer. Reworks the related bits of the native skin (+ a few minor changes for posix and rtdm) to support the named interrupt objects. 2) shirq-v7.patch Generic support for shared interrupts. 3) shirq-proc.patch /proc support. Now /proc/xenomai/irq shows the names of handlers. The related code have been removed from the hal layer to nucleus. - 4) shirq-isa.patch Trying to handle the edge-triggered stuff. This is a very preliminary version so the only thing I promise so far is that it compiles successfully. Why not name it XN_ISR_EDGE or so (also the related functions etc.)?Although it mostly targets ISA hardware, it's about the edge-triggeredcharacteristic of that devices after all. Ack. I forgot to apply your earlier fixes so it will be done too. The functionality added by first 3 patches seem to be working. -- Best regards, Dmitry AdamushkoI'm now trying to organise a full test scenario with shared UARTISA-IRQs at our institute. May take till beginning of next week, some regressions in our own software need to be fixed first. That's good. Thanks. Keep me informed on progress. Jan-- Best regards,Dmitry Adamushko
[Xenomai-core] some results on my laptop
some random sucesses .. Ive been running an ipipe kernel as the default since shortly after 1/7. Since then, Ive had a couple of freezes on boot, and sometimes bash's auto-complete takes longer to complete, but other than that, things have been solid. But that kernel wasnt configured using scripts/prepare-kernel.sh, so was missing the xeno_* modules. [EMAIL PROTECTED] latency]$ sudo ./run -- -T 120 -h * * * Type ^C to stop this application. * * == Sampling period: 100 us == Test mode: periodic user-mode task warming up... RTT| 00:00:05 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -4749| -4585| -3921| 0| -4749| -3921 RTD| -4749| -4583| -3015| 0| -4749| -3015 RTD| -4749| -4578| -2685| 0| -4749| -2685 RTD| -4750| -4581| -3015| 0| -4750| -2685 RTD| -4812| -4578| -3049| 0| -4812| -2685 RTD| -4757| -4584| -3785| 0| -4812| -2685 RTD| -4798| -4584| -2636| 0| -4812| -2636 RTD| -4757| -4582| -3029| 0| -4812| -2636 RTD| -4748| -4582| -3906| 0| -4812| -2636 RTD| -4751| -4582| -2666| 0| -4812| -2636 RTD| -4752| -4582| -2806| 0| -4812| -2636 RTD| -4748| -4581| -3157| 0| -4812| -2636 RTD| -4750| -4583| -2882| 0| -4812| -2636 RTD| -4779| -4583| -2816| 0| -4812| -2636 RTD| -4804| -4585| -2979| 0| -4812| -2636 RTD| -4747| -4583| -2684| 0| -4812| -2636 RTD| -4761| -4583| -2600| 0| -4812| -2600 RTD| -4763| -4583| -2782| 0| -4812| -2600 RTD| -4807| -4584| -2582| 0| -4812| -2582 RTD| -4787| -4582| -2721| 0| -4812| -2582 RTD| -4766| -4584| -2713| 0| -4812| -2582 RTT| 00:01:04 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -4750| -4584| -2936| 0| -4812| -2582 RTD| -4749| -4585| -2736| 0| -4812| -2582 RTD| -4814| -4586| -2935| 0| -4814| -2582 RTD| -4781| -4584| -2884| 0| -4814| -2582 RTD| -4749| -4579| -2743| 0| -4814| -2582 RTD| -4749| -4580| -2708| 0| -4814| -2582 RTD| -4750| -4585| -2870| 0| -4814| -2582 RTD| -4748| -4584| -2761| 0| -4814| -2582 RTD| -4766| -4585| -3152| 0| -4814| -2582 RTD| -4755| -4584| -3001| 0| -4814| -2582 RTD| -4749| -4584| -2810| 0| -4814| -2582 RTD| -4748| -4584| -2935| 0| -4814| -2582 RTD| -4754| -4584| -2734| 0| -4814| -2582 RTD| -4789| -4586| -3109| 0| -4814| -2582 RTD| -4765| -4583| -2835| 0| -4814| -2582 RTD| -4751| -4584| -2767| 0| -4814| -2582 RTD| -4750| -4582| -2831| 0| -4814| -2582 RTD| -4750| -4585| -2829| 0| -4814| -2582 RTD| -4782| -4584| -2751| 0| -4814| -2582 RTD| -4750| -4584| -2851| 0| -4814| -2582 ---|--param|range-|--samples HSD|min| 4 - 5 | 41 ---|--param|range-|--samples HSD|avg| 2 - 3 | 60 HSD|avg| 3 - 4 | 429 HSD|avg| 4 - 5 | 416620 ---|--param|range-|--samples HSD|max| 2 - 3 | 30 HSD|max| 3 - 4 | 11 HSH|--param|--samples-|--average--|---stddev-- HSS|min|41| 4.000| 0.000 HSS|avg|417109| 3.999| 0.040 HSS|max|41| 2.268| 0.449 ---|||||- RTS| -4814| -4583| -2582| 0|00:02:00/00:02:00 This was run on a pentium-M laptop, with cpu-clock running at 600 MHz, (capable of 1.7 GHz) I presume this might explain the negative latancies. Im aware this is un-supported .. The only thing that looks wrong is the test-duration. I asked for 120 sec, it gave me 40 samples. The test did take 120 to run.
