Re: [Xenomai-core] [PATCH] Shared irqs v.6
Jeroen Van den Keybus wrote:
>>> I mean that the support of shared interrupts for ISA boards
>> (edge-triggered
>>> stuff) is a kind of emulation to overcome the shortcommings of the
>> initial
>>> design on the hardware level. The hardware was just not supposed to
>> support
>>> shared interrupt channels. So, let's keep it a bit aside from another
>> code
>>> :o)
>> Unfortunately, this crappy hardware is still quite common in the
>> embedded domain.
>
>
> If I've understood correctly, the only reason for having this support is to
> avoid - after discovering an interrupting UART - that the IRQ line remains
> high upon exit, which would cause the 8259 not to issue the CPU IRQ for that
> line anymore ?
Yep.
>
> The proposed solution is therefore to traverse the entire list of
> UARTs connected to that IRQ line and make sure none of them was interrupting
> in two consecutive passes (by checking their status registers). That would
> mean the IRQ line must be deasserted and the 8259 will properly detect any
> newly arriving interrupts, since the 8259 has been acknowledged before
> handling the interrupt.
Yep.
>
> 1. Wouldn't it be more efficient to make this a compile-time option, instead
> of burdening the nucleus with it ?
You need this feature per-IRQ as there will always be also usual
level-triggered IRQs on your system. What Dmitry is now heading for is a
runtime selection of the fitting IRQ trampoline at nucleus level.
> 2. Would it be an option, in the embedded boards Jan is speaking of, to put
> the 8259 in level sensitive mode ? Some of the boards I know don't actually
> have this selection logic for the built-in interrupt sources such as the
> timer and the IDE I/F and it therefore only applies to the ISA bus.
Might be an option, but I'm not THAT deep into it to asses all possible
pitfalls of such an approach. Has anyone ever tried this in reality?
> 3. Beware of UARTs that cause interrupts and have a problem that causes them
> to spuriously return 'all green' upon reading of the IIR register. I have
> dealt with an integrated ('Super I/O') card with that problem before. The
> only solution was to look at LSR and check THRE as well, even when no TX
> interrupt was seemingly present. Must be a logic race.
Yes, there is always the risk of running onto such hardware. Luckily, we
haven't "found" any of it on our systems so far (once you picked
reasonable hardware, you should stay with it - just like we do :) ).
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Shared irqs v.6
> I mean that the support of shared interrupts for ISA boards (edge-triggered> stuff) is a kind of emulation to overcome the shortcommings of the initial
> design on the hardware level. The hardware was just not supposed to support> shared interrupt channels. So, let's keep it a bit aside from another code> :o)Unfortunately, this crappy hardware is still quite common in the
embedded domain.
If I've understood correctly, the only reason for having this support is to avoid - after discovering an interrupting UART - that the IRQ line remains high upon exit, which would cause the 8259 not to issue the CPU IRQ for that line anymore ?
The proposed solution is therefore to traverse the entire list of UARTs connected to that IRQ line and make sure none of them was interrupting in two consecutive passes (by checking their status registers). That would mean the IRQ line must be deasserted and the 8259 will properly detect any newly arriving interrupts, since the 8259 has been acknowledged before handling the interrupt.
1. Wouldn't it be more efficient to make this a compile-time option, instead of burdening the nucleus with it ?
2. Would it be an option, in the embedded boards Jan is speaking of, to put the 8259 in level sensitive mode ? Some of the boards I know don't actually have this selection logic for the built-in interrupt sources such as the timer and the IDE I/F and it therefore only applies to the ISA bus.
3. Beware of UARTs that cause interrupts and have a problem that causes them to spuriously return 'all green' upon reading of the IIR register. I have dealt with an integrated ('Super I/O') card with that problem before. The only solution was to look at LSR and check THRE as well, even when no TX interrupt was seemingly present. Must be a logic race.
Jeroen.
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Jeroen Van den Keybus wrote:
>>> I mean that the support of shared interrupts for ISA boards
>> (edge-triggered
>>> stuff) is a kind of emulation to overcome the shortcommings of the
>> initial
>>> design on the hardware level. The hardware was just not supposed to
>> support
>>> shared interrupt channels. So, let's keep it a bit aside from another
>> code
>>> :o)
>> Unfortunately, this crappy hardware is still quite common in the
>> embedded domain.
>
>
> If I've understood correctly, the only reason for having this support is to
> avoid - after discovering an interrupting UART - that the IRQ line remains
> high upon exit, which would cause the 8259 not to issue the CPU IRQ for that
> line anymore ?
Yep.
>
> The proposed solution is therefore to traverse the entire list of
> UARTs connected to that IRQ line and make sure none of them was interrupting
> in two consecutive passes (by checking their status registers). That would
> mean the IRQ line must be deasserted and the 8259 will properly detect any
> newly arriving interrupts, since the 8259 has been acknowledged before
> handling the interrupt.
Yep.
>
> 1. Wouldn't it be more efficient to make this a compile-time option, instead
> of burdening the nucleus with it ?
You need this feature per-IRQ as there will always be also usual
level-triggered IRQs on your system. What Dmitry is now heading for is a
runtime selection of the fitting IRQ trampoline at nucleus level.
> 2. Would it be an option, in the embedded boards Jan is speaking of, to put
> the 8259 in level sensitive mode ? Some of the boards I know don't actually
> have this selection logic for the built-in interrupt sources such as the
> timer and the IDE I/F and it therefore only applies to the ISA bus.
Might be an option, but I'm not THAT deep into it to asses all possible
pitfalls of such an approach. Has anyone ever tried this in reality?
> 3. Beware of UARTs that cause interrupts and have a problem that causes them
> to spuriously return 'all green' upon reading of the IIR register. I have
> dealt with an integrated ('Super I/O') card with that problem before. The
> only solution was to look at LSR and check THRE as well, even when no TX
> interrupt was seemingly present. Must be a logic race.
Yes, there is always the risk of running onto such hardware. Luckily, we
haven't "found" any of it on our systems so far (once you picked
reasonable hardware, you should stay with it - just like we do :) ).
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] [PATCH] Shared irqs v.6
> I mean that the support of shared interrupts for ISA boards (edge-triggered> stuff) is a kind of emulation to overcome the shortcommings of the initial
> design on the hardware level. The hardware was just not supposed to support> shared interrupt channels. So, let's keep it a bit aside from another code> :o)Unfortunately, this crappy hardware is still quite common in the
embedded domain.
If I've understood correctly, the only reason for having this support is to avoid - after discovering an interrupting UART - that the IRQ line remains high upon exit, which would cause the 8259 not to issue the CPU IRQ for that line anymore ?
The proposed solution is therefore to traverse the entire list of UARTs connected to that IRQ line and make sure none of them was interrupting in two consecutive passes (by checking their status registers). That would mean the IRQ line must be deasserted and the 8259 will properly detect any newly arriving interrupts, since the 8259 has been acknowledged before handling the interrupt.
1. Wouldn't it be more efficient to make this a compile-time option, instead of burdening the nucleus with it ?
2. Would it be an option, in the embedded boards Jan is speaking of, to put the 8259 in level sensitive mode ? Some of the boards I know don't actually have this selection logic for the built-in interrupt sources such as the timer and the IDE I/F and it therefore only applies to the ISA bus.
3. Beware of UARTs that cause interrupts and have a problem that causes them to spuriously return 'all green' upon reading of the IIR register. I have dealt with an integrated ('Super I/O') card with that problem before. The only solution was to look at LSR and check THRE as well, even when no TX interrupt was seemingly present. Must be a logic race.
Jeroen.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote: > On 31/01/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> Dmitry Adamushko wrote: >>> Hi, >>> >>> the previous version contained an ugly bug, namely the misuse of the >>> test_and_set/clear_bit interface >>> that led to a broken system from time to time. >>> >> What about the ISA/edge-triggered stuff? :D >> >> My problem is that we cannot test here on real hardware because all our >> shared IRQs reside on PC104 cards. > > > Could you provide me with some real piece of such code as an example? May I remind you of the link to the linux kernel's 8250 driver I gave? Or what do you mean with real code? xeno_16550A would become such a user ideally only by adding one or two IRQ-registration flags. > > Anyway, design-wise, it's about introducing a separate xnintr_handler() for > such a special case to avoid getting a mixture with the rest of "sane" code. Yep, I would vote for this approach as well. > I mean that the support of shared interrupts for ISA boards (edge-triggered > stuff) is a kind of emulation to overcome the shortcommings of the initial > design on the hardware level. The hardware was just not supposed to support > shared interrupt channels. So, let's keep it a bit aside from another code > :o) Unfortunately, this crappy hardware is still quite common in the embedded domain. > > xnintr_attach() will check for a special flag like XN_ISR_ISASHARED and > attach e.g. xnintr_isairq_handler() instead of xnintr_irq_handler(). > > I'll post an extension to the rt_intr_create(..., const char *name, ...) > tomorrow - made but not tested yet - > > as well as the /proc support. > This should be easy... Great! Jan
Re: [Xenomai-core] [PATCH] Shared irqs v.6
On 31/01/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: Dmitry Adamushko wrote:> Hi,>> the previous version contained an ugly bug, namely the misuse of the> test_and_set/clear_bit interface> that led to a broken system from time to time.> What about the ISA/edge-triggered stuff? :DMy problem is that we cannot test here on real hardware because all ourshared IRQs reside on PC104 cards. Could you provide me with some real piece of such code as an example? Anyway, design-wise, it's about introducing a separate xnintr_handler() for such a special case to avoid getting a mixture with the rest of "sane" code. I mean that the support of shared interrupts for ISA boards (edge-triggered stuff) is a kind of emulation to overcome the shortcommings of the initial design on the hardware level. The hardware was just not supposed to support shared interrupt channels. So, let's keep it a bit aside from another code :o) xnintr_attach() will check for a special flag like XN_ISR_ISASHARED and attach e.g. xnintr_isairq_handler() instead of xnintr_irq_handler(). I'll post an extension to the rt_intr_create(..., const char *name, ...) tomorrow - made but not tested yet - as well as the /proc support. Jan-- Best regards,Dmitry Adamushko
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote:
> Hi,
>
> the previous version contained an ugly bug, namely the misuse of the
> test_and_set/clear_bit interface
> that led to a broken system from time to time.
>
And here is a tiny patch to make RTDM shared-IRQ-aware. If you release
another version before a merge, you may include it into your patch.
Note that I struggled a bit with finding the right prefix. I decided to
separate the namespaces of return flags and creation flags - hopefully
in a reasonable manner.
Jan
Index: ksrc/skins/rtdm/drvlib.c
===
--- ksrc/skins/rtdm/drvlib.c(revision 503)
+++ ksrc/skins/rtdm/drvlib.c(working copy)
@@ -1200,7 +1200,7 @@
* @param[in,out] irq_handle IRQ handle
* @param[in] irq_no Line number of the addressed IRQ
* @param[in] handler Interrupt handler
- * @param[in] flags Currently unused, pass 0
+ * @param[in] flags Registration flags, see @ref RTDM_IRQTYPE_xxx for details
* @param[in] device_name Optional device name to show up in real-time IRQ
* lists (not yet implemented)
* @param[in] arg Pointer to be passed to the interrupt handler on invocation
Index: include/rtdm/rtdm_driver.h
===
--- include/rtdm/rtdm_driver.h (revision 503)
+++ include/rtdm/rtdm_driver.h (working copy)
@@ -693,6 +693,15 @@
typedef xnintr_trtdm_irq_t;
+/*!
+ * @anchor RTDM_IRQTYPE_xxx @name RTDM_IRQTYPE_xxx
+ * Interrupt registrations flags
+ * @{
+ */
+/** Enable IRQ-sharing with other real-time drivers */
+#define RTDM_IRQTYPE_SHARED XN_ISR_SHARED
+/** @} */
+
/**
* Interrupt handler
*
@@ -702,7 +711,6 @@
*/
typedef int (*rtdm_irq_handler_t)(rtdm_irq_t *irq_handle);
-
/*!
* @anchor RTDM_IRQ_xxx @name RTDM_IRQ_xxx
* Return flags of interrupt handlers
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote: > Hi, > > the previous version contained an ugly bug, namely the misuse of the > test_and_set/clear_bit interface > that led to a broken system from time to time. > What about the ISA/edge-triggered stuff? :D My problem is that we cannot test here on real hardware because all our shared IRQs reside on PC104 cards. Jan PS: I guess this one does not add much functionality: ;) @@ -181,8 +235,7 @@ int xnintr_destroy (xnintr_t *intr) * * @param cookie A user-defined opaque value which is stored into the * interrupt object descriptor for further retrieval by the ISR/ISR - * handlers. - * + * handlers. * * @return 0 is returned on success. Otherwise, -EINVAL is returned if * a low-level error occurred while attaching the interrupt. -EBUSY is * specifically returned if the interrupt object was already attached. signature.asc Description: OpenPGP digital signature
[Xenomai-core] [PATCH] Shared irqs v.6
Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. -- Best regards,Dmitry Adamushko shirq-v6.patch Description: Binary data
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote: > On 31/01/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> Dmitry Adamushko wrote: >>> Hi, >>> >>> the previous version contained an ugly bug, namely the misuse of the >>> test_and_set/clear_bit interface >>> that led to a broken system from time to time. >>> >> What about the ISA/edge-triggered stuff? :D >> >> My problem is that we cannot test here on real hardware because all our >> shared IRQs reside on PC104 cards. > > > Could you provide me with some real piece of such code as an example? May I remind you of the link to the linux kernel's 8250 driver I gave? Or what do you mean with real code? xeno_16550A would become such a user ideally only by adding one or two IRQ-registration flags. > > Anyway, design-wise, it's about introducing a separate xnintr_handler() for > such a special case to avoid getting a mixture with the rest of "sane" code. Yep, I would vote for this approach as well. > I mean that the support of shared interrupts for ISA boards (edge-triggered > stuff) is a kind of emulation to overcome the shortcommings of the initial > design on the hardware level. The hardware was just not supposed to support > shared interrupt channels. So, let's keep it a bit aside from another code > :o) Unfortunately, this crappy hardware is still quite common in the embedded domain. > > xnintr_attach() will check for a special flag like XN_ISR_ISASHARED and > attach e.g. xnintr_isairq_handler() instead of xnintr_irq_handler(). > > I'll post an extension to the rt_intr_create(..., const char *name, ...) > tomorrow - made but not tested yet - > > as well as the /proc support. > This should be easy... Great! Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
On 31/01/06, Jan Kiszka <[EMAIL PROTECTED]> wrote: Dmitry Adamushko wrote:> Hi,>> the previous version contained an ugly bug, namely the misuse of the> test_and_set/clear_bit interface> that led to a broken system from time to time.> What about the ISA/edge-triggered stuff? :DMy problem is that we cannot test here on real hardware because all ourshared IRQs reside on PC104 cards. Could you provide me with some real piece of such code as an example? Anyway, design-wise, it's about introducing a separate xnintr_handler() for such a special case to avoid getting a mixture with the rest of "sane" code. I mean that the support of shared interrupts for ISA boards (edge-triggered stuff) is a kind of emulation to overcome the shortcommings of the initial design on the hardware level. The hardware was just not supposed to support shared interrupt channels. So, let's keep it a bit aside from another code :o) xnintr_attach() will check for a special flag like XN_ISR_ISASHARED and attach e.g. xnintr_isairq_handler() instead of xnintr_irq_handler(). I'll post an extension to the rt_intr_create(..., const char *name, ...) tomorrow - made but not tested yet - as well as the /proc support. Jan-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote:
> Hi,
>
> the previous version contained an ugly bug, namely the misuse of the
> test_and_set/clear_bit interface
> that led to a broken system from time to time.
>
And here is a tiny patch to make RTDM shared-IRQ-aware. If you release
another version before a merge, you may include it into your patch.
Note that I struggled a bit with finding the right prefix. I decided to
separate the namespaces of return flags and creation flags - hopefully
in a reasonable manner.
Jan
Index: ksrc/skins/rtdm/drvlib.c
===
--- ksrc/skins/rtdm/drvlib.c(revision 503)
+++ ksrc/skins/rtdm/drvlib.c(working copy)
@@ -1200,7 +1200,7 @@
* @param[in,out] irq_handle IRQ handle
* @param[in] irq_no Line number of the addressed IRQ
* @param[in] handler Interrupt handler
- * @param[in] flags Currently unused, pass 0
+ * @param[in] flags Registration flags, see @ref RTDM_IRQTYPE_xxx for details
* @param[in] device_name Optional device name to show up in real-time IRQ
* lists (not yet implemented)
* @param[in] arg Pointer to be passed to the interrupt handler on invocation
Index: include/rtdm/rtdm_driver.h
===
--- include/rtdm/rtdm_driver.h (revision 503)
+++ include/rtdm/rtdm_driver.h (working copy)
@@ -693,6 +693,15 @@
typedef xnintr_trtdm_irq_t;
+/*!
+ * @anchor RTDM_IRQTYPE_xxx @name RTDM_IRQTYPE_xxx
+ * Interrupt registrations flags
+ * @{
+ */
+/** Enable IRQ-sharing with other real-time drivers */
+#define RTDM_IRQTYPE_SHARED XN_ISR_SHARED
+/** @} */
+
/**
* Interrupt handler
*
@@ -702,7 +711,6 @@
*/
typedef int (*rtdm_irq_handler_t)(rtdm_irq_t *irq_handle);
-
/*!
* @anchor RTDM_IRQ_xxx @name RTDM_IRQ_xxx
* Return flags of interrupt handlers
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Shared irqs v.6
Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time. -- Best regards,Dmitry Adamushko shirq-v6.patch Description: Binary data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Shared irqs v.6
Dmitry Adamushko wrote: > Hi, > > the previous version contained an ugly bug, namely the misuse of the > test_and_set/clear_bit interface > that led to a broken system from time to time. > What about the ISA/edge-triggered stuff? :D My problem is that we cannot test here on real hardware because all our shared IRQs reside on PC104 cards. Jan PS: I guess this one does not add much functionality: ;) @@ -181,8 +235,7 @@ int xnintr_destroy (xnintr_t *intr) * * @param cookie A user-defined opaque value which is stored into the * interrupt object descriptor for further retrieval by the ISR/ISR - * handlers. - * + * handlers. * * @return 0 is returned on success. Otherwise, -EINVAL is returned if * a low-level error occurred while attaching the interrupt. -EBUSY is * specifically returned if the interrupt object was already attached. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
