Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Wolfgang Grandegger wrote: Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED - RT_INTR_CHAINED - RT_INTR_ENABLE - RT_INTR_NOINT or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, I Ok, that's a good argument. Then make the whole IRQ-sharing stuff compile-time configurable and see how much we can save. don't have the time to follow all the details of the rapid Xenomai development and can't therefore judge what is really necessary. Wolfgang. 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] [Combo-PATCH] Shared interrupts (final)
On 08/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, IOk, that's a good argument. Then make the whole IRQ-sharing stuffcompile-time configurable and see how much we can save. Anyway, I agree that the code which is supposed to be used by only a fraction of users (Jan is only interested so far? and esp. in that brain-damaged edge-triggered stuff) and which is a bit too heavy to guarantee a close-to-zero-overhead should be made optional. Ok, let's go for it upon getting the test results. Enclosed a small optimization to reduce the code in (optional in future) ISR. Jan -- Best regards,Dmitry Adamushko shirq-v9.patch Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED ISR says it has handled the IRQ, and does not want any propagation to take place down the pipeline. IOW, the IRQ processing stops there. - RT_INTR_CHAINED ISR says it wants the IRQ to be propagated down the pipeline. Nothing is said about the fact that the last ISR did or did not handle the IRQ locally; this is irrelevant. - RT_INTR_ENABLE ISR requests the interrupt dispatcher to re-enable the IRQ line upon return (cumulable with HANDLED/CHAINED). - RT_INTR_NOINT This new one comes from Dmitry's patch for shared IRQ support AFAICS. It would mean to continue processing the chain of handlers because the last ISR invoked was not concerned by the outstanding IRQ. or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I support that. Shared interrupts should be handled properly by Xeno since such - I'd say last resort - configuration could be needed; this said, we should not see this as the rule but rather as the exception, since this is basically required to solve some underlying hw limitations wrt interrupt management, and definitely has a significant cost on processing each shared IRQ wrt determinism. Incidentally, there is an interesting optimization on the project's todo list that would allow non-RT interrupts to be masked at IC level when the Xenomai domain is active. We could do that on any arch with civilized interrupt management, and that would prevent any asynchronous diversion from the critical code when Xenomai is running RT tasks (kernel or user-space). Think of this as some hw-controlled interrupt shield. Since this feature requires to be able to individually mask each interrupt source at IC level, there should be no point in sharing fully vectored interrupts in such a configuration anyway. This fact also pleads for having the shared IRQ support as a build-time option. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Slow is faster arch/ppc/syslib/open_pic.c
Philippe Gerum wrote:
Philippe Gerum wrote:
Anders Blomdell wrote:
When trying to run Xenomai on PowerPC with OpenPIC, I have (finally)
found that interrupt latency is much improved with the following patch:
--- arch/ppc/syslib/open_pic.c~ 2006-01-08 03:15:24.0 +0100
+++ arch/ppc/syslib/open_pic.c 2006-02-07 16:56:14.0 +0100
@@ -820,7 +820,7 @@
*/
static void openpic_ack_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
@@ -831,7 +831,7 @@
static void openpic_end_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
if (!(irq_desc[irq_nr].status (IRQ_DISABLED|IRQ_INPROGRESS))
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
The reason for this, is that the fast version doesn't call
openpic_eoi until the interrupt is ended, which means that all
RT-interrupts are delayed by a pending Linux interrupt.
Gasp. Will check on my Icecube asap, thanks (a lot).
The mpc52xx is using its own version of PIC management - which should
not induce such delay on eoi, so I cannot experiment this change yet.
However, I've revisited your patch so that the OpenPIC code always sends
eoi in fast mode, regardless of the interrupt polarity. Could you try
the patch below and let me know of the outcome? TIA,
Ok. Drop this to /dev/null. I've misread the original -ack() code, and as you
pointed out, this patch would not work. -ENOBRAIN again.
--- arch/ppc/syslib/open_pic.c~2005-10-28 02:02:08.0 +0200
+++ arch/ppc/syslib/open_pic.c2006-02-08 10:30:22.0 +0100
@@ -824,7 +824,9 @@
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) == 0)
+#endif /* CONFIG_IPIPE */
openpic_eoi();
#endif
}
@@ -836,8 +838,10 @@
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) != 0)
openpic_eoi();
+#endif /* CONFIG_IPIPE */
#endif
}
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Watchdog/Interrupt management
ROSSIER Daniel wrote: Hi Philippe, -Message d'origine- De : Philippe Gerum [mailto:[EMAIL PROTECTED] Envoyé : mardi, 7. février 2006 14:45 À : ROSSIER Daniel Cc : xenomai-core@gna.org Objet : Re: [Xenomai-core] Watchdog/Interrupt management ROSSIER Daniel wrote: Hi all, I've a - probably small ;-) - issue regarding the way how the watchdog and interrupt management are working together. I'd like to implement a watchdog in a task to ensure that a task is well alive at periodic interval. For doing some tests, I've implemented a small ISR which interceipts the keyboard interrupts (IRQ 1). The ISR is simply doing some busy wait burning CPU time, but with a delay greater than the task period. I assume that the ISR locks the rescheduling procedure as it is stated in the API doc (BTW; many thanks for having solved the doc issue). So, the task switching is temporarly suspended and the watchdog should raise up an alarm after the ISR has been completed, right? It doesn't. Because Adeos disables interrupts by default when calling an ISR from a non-Linux domain (like Xenomai's). You can re-enable them to get nested interrupts by doing this in your ISR: unsigned long flags; rthal_local_irq_sync(flags); spin rthal_local_irq_restore(flags); Please, could you just provide me with a small explanation about what the rthal_local_irq_sync() function is doing? This unstalls Xeno's pipeline stage and re-enables hw interrupts in the same time when entering your ISR, then restores the original masking before returning to the nucleus. I've attached the code below (I've removed the function return check for readibility reasons, but all objects are fine). Another question: the ISR is called on behalf of the interrupted stack context: does it mean that the ISR always runs in the stack context of the highest priority task, i.e. the running task (assume no inversion priority), or could it in some cases the kernel stack context (if ADEOS is currently doing some interruptible stuff..) I-pipe Adeos versions always run interrupt handlers over the stack of the preempted context. So, I presume I can use the rt_task_self() function to get the task which has been pre-empted, right? (and I've always a valid task) rt_task_self() always returns NULL when called over an ISR. Thanks for your help. Daniel -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED - RT_INTR_CHAINED - RT_INTR_ENABLE - RT_INTR_NOINT or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, I don't have the time to follow all the details of the rapid Xenomai development and can't therefore judge what is really necessary. Wolfgang. Jan
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
Wolfgang Grandegger wrote: Jan Kiszka wrote: Wolfgang Grandegger wrote: Hello, Dmitry Adamushko wrote: Hi, this is the final set of patches against the SVN trunk of 2006-02-03. It addresses mostly remarks concerning naming (XN_ISR_ISA - XN_ISR_EDGE), a few cleanups and updated comments. Functionally, the support for shared interrupts (a few flags) to the Not directly your fault: the increasing number of return flags for IRQ handlers makes me worry that they are used correctly. I can figure out what they mean (not yet that clearly from the docs), but does someone else understand all this: - RT_INTR_HANDLED - RT_INTR_CHAINED - RT_INTR_ENABLE - RT_INTR_NOINT or - RTDM_IRQ_PROPAGATE - RTDM_IRQ_ENABLE - RTDM_IRQ_NOINT Third-party comments / suggestions welcome as well. Maybe I'm too pessimistic. rtdm (Jan's patch) and native skin. In the later case, rt_intr_create() now contains the 6-th argument, namely int mode. Now I'm waiting for the test results from Jan (the previous patch-set remains to be suitable for testing too in case you are using it already). Upon success, the new code is ready for merging. Trying to manage the priority list of someone else is tricky - I hope we can see something soon, but I cannot promise anything. the patches have to be applied as follows : - shirq-base - shirq-v8 - shirq-proc - shirq-edge - shirq-ext Happy testing ! :) My concern is code size. I see that the patches add substantial amount of code to the ISR. What about make this feature configurable? I would vote for the (already scheduled?) extension to register an optimised IRQ trampoline in case there is actually no sharing taking place. This would also make the if (irq == XNARCH_TIMER_IRQ) path obsolete. I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, I Ok, that's a good argument. Then make the whole IRQ-sharing stuff compile-time configurable and see how much we can save. don't have the time to follow all the details of the rapid Xenomai development and can't therefore judge what is really necessary. Wolfgang. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Slow is faster arch/ppc/syslib/open_pic.c
Philippe Gerum wrote:
Anders Blomdell wrote:
When trying to run Xenomai on PowerPC with OpenPIC, I have (finally)
found that interrupt latency is much improved with the following patch:
--- arch/ppc/syslib/open_pic.c~ 2006-01-08 03:15:24.0 +0100
+++ arch/ppc/syslib/open_pic.c 2006-02-07 16:56:14.0 +0100
@@ -820,7 +820,7 @@
*/
static void openpic_ack_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
@@ -831,7 +831,7 @@
static void openpic_end_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
if (!(irq_desc[irq_nr].status (IRQ_DISABLED|IRQ_INPROGRESS))
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
The reason for this, is that the fast version doesn't call openpic_eoi
until the interrupt is ended, which means that all RT-interrupts are
delayed by a pending Linux interrupt.
Gasp. Will check on my Icecube asap, thanks (a lot).
The mpc52xx is using its own version of PIC management - which should not induce
such delay on eoi, so I cannot experiment this change yet. However, I've revisited
your patch so that the OpenPIC code always sends eoi in fast mode, regardless of
the interrupt polarity. Could you try the patch below and let me know of the
outcome? TIA,
--- arch/ppc/syslib/open_pic.c~ 2005-10-28 02:02:08.0 +0200
+++ arch/ppc/syslib/open_pic.c 2006-02-08 10:30:22.0 +0100
@@ -824,7 +824,9 @@
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) == 0)
+#endif /* CONFIG_IPIPE */
openpic_eoi();
#endif
}
@@ -836,8 +838,10 @@
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) != 0)
openpic_eoi();
+#endif /* CONFIG_IPIPE */
#endif
}
--
Philippe.
Re: [Xenomai-core] [Combo-PATCH] Shared interrupts (final)
On 08/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: I still prefer configuration options as they also allow to reduce the overall code size (less cache refills and TLB misses). And shared interrupts are for x86 only (approximately), I think. Unfortunately, IOk, that's a good argument. Then make the whole IRQ-sharing stuffcompile-time configurable and see how much we can save. Anyway, I agree that the code which is supposed to be used by only a fraction of users (Jan is only interested so far? and esp. in that brain-damaged edge-triggered stuff) and which is a bit too heavy to guarantee a close-to-zero-overhead should be made optional. Ok, let's go for it upon getting the test results. Enclosed a small optimization to reduce the code in (optional in future) ISR. Jan -- Best regards,Dmitry Adamushko shirq-v9.patch Description: Binary data
Re: [Xenomai-core] [PATCH] Slow is faster arch/ppc/syslib/open_pic.c
Philippe Gerum wrote:
Philippe Gerum wrote:
Anders Blomdell wrote:
When trying to run Xenomai on PowerPC with OpenPIC, I have (finally)
found that interrupt latency is much improved with the following patch:
--- arch/ppc/syslib/open_pic.c~ 2006-01-08 03:15:24.0 +0100
+++ arch/ppc/syslib/open_pic.c 2006-02-07 16:56:14.0 +0100
@@ -820,7 +820,7 @@
*/
static void openpic_ack_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
@@ -831,7 +831,7 @@
static void openpic_end_irq(unsigned int irq_nr)
{
-#ifdef __SLOW_VERSION__
+#if defined(__SLOW_VERSION__) || defined(CONFIG_IPIPE)
if (!(irq_desc[irq_nr].status (IRQ_DISABLED|IRQ_INPROGRESS))
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
The reason for this, is that the fast version doesn't call
openpic_eoi until the interrupt is ended, which means that all
RT-interrupts are delayed by a pending Linux interrupt.
Gasp. Will check on my Icecube asap, thanks (a lot).
The mpc52xx is using its own version of PIC management - which should
not induce such delay on eoi, so I cannot experiment this change yet.
However, I've revisited your patch so that the OpenPIC code always sends
eoi in fast mode, regardless of the interrupt polarity. Could you try
the patch below and let me know of the outcome? TIA,
Ok. Drop this to /dev/null. I've misread the original -ack() code, and as you
pointed out, this patch would not work. -ENOBRAIN again.
--- arch/ppc/syslib/open_pic.c~2005-10-28 02:02:08.0 +0200
+++ arch/ppc/syslib/open_pic.c2006-02-08 10:30:22.0 +0100
@@ -824,7 +824,9 @@
openpic_disable_irq(irq_nr);
openpic_eoi();
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) == 0)
+#endif /* CONFIG_IPIPE */
openpic_eoi();
#endif
}
@@ -836,8 +838,10 @@
irq_desc[irq_nr].action)
openpic_enable_irq(irq_nr);
#else
+#ifndef CONFIG_IPIPE
if ((irq_desc[irq_nr].status IRQ_LEVEL) != 0)
openpic_eoi();
+#endif /* CONFIG_IPIPE */
#endif
}
--
Philippe.
Re: [Xenomai-core] Watchdog/Interrupt management
ROSSIER Daniel wrote: Hi Philippe, -Message d'origine- De : Philippe Gerum [mailto:[EMAIL PROTECTED] Envoyé : mardi, 7. février 2006 14:45 À : ROSSIER Daniel Cc : xenomai-core@gna.org Objet : Re: [Xenomai-core] Watchdog/Interrupt management ROSSIER Daniel wrote: Hi all, I've a - probably small ;-) - issue regarding the way how the watchdog and interrupt management are working together. I'd like to implement a watchdog in a task to ensure that a task is well alive at periodic interval. For doing some tests, I've implemented a small ISR which interceipts the keyboard interrupts (IRQ 1). The ISR is simply doing some busy wait burning CPU time, but with a delay greater than the task period. I assume that the ISR locks the rescheduling procedure as it is stated in the API doc (BTW; many thanks for having solved the doc issue). So, the task switching is temporarly suspended and the watchdog should raise up an alarm after the ISR has been completed, right? It doesn't. Because Adeos disables interrupts by default when calling an ISR from a non-Linux domain (like Xenomai's). You can re-enable them to get nested interrupts by doing this in your ISR: unsigned long flags; rthal_local_irq_sync(flags); spin rthal_local_irq_restore(flags); Please, could you just provide me with a small explanation about what the rthal_local_irq_sync() function is doing? This unstalls Xeno's pipeline stage and re-enables hw interrupts in the same time when entering your ISR, then restores the original masking before returning to the nucleus. I've attached the code below (I've removed the function return check for readibility reasons, but all objects are fine). Another question: the ISR is called on behalf of the interrupted stack context: does it mean that the ISR always runs in the stack context of the highest priority task, i.e. the running task (assume no inversion priority), or could it in some cases the kernel stack context (if ADEOS is currently doing some interruptible stuff..) I-pipe Adeos versions always run interrupt handlers over the stack of the preempted context. So, I presume I can use the rt_task_self() function to get the task which has been pre-empted, right? (and I've always a valid task) rt_task_self() always returns NULL when called over an ISR. Thanks for your help. Daniel -- Philippe.
