Philippe Gerum wrote:
On Tue, 2006-09-12 at 12:37 +0200, Wolfgang Grandegger wrote:
Matthias Fuchs wrote:
On Monday 11 September 2006 20:13, Wolfgang Grandegger wrote:
In 2.6 the interrupts are disabled by default. Then the attached patch for Xenomai should help.


Your patch also works fine. Now what's the recommended solution? I noticed that Philippe already checked in an Adeos fix.
As mentioned, in Linux 2.6 (generic IRQ layer), IRQs are disabled by default in kernel/irq/handle.c:

   irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
         [0 ... NR_IRQS-1] = {
                 .status = IRQ_DISABLED,
                 .handler = &no_irq_type,
                 .lock = SPIN_LOCK_UNLOCKED

Till now, I haven't found IPIPE/Xenomai related code removing the IRQ_DISABLED bit. But I wonder why it's working for x86. Maybe I have missed something.

In Linux 2.4, the "status" field is initialized to 0 (in arch/ppc/kernel/irq.c) not making trouble:

   irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned =
         { [0 ... NR_IRQS-1] = { 0, NULL, NULL, 0, SPIN_LOCK_UNLOCKED}};

At least my CAN PCI card on a MPC5200 works fine.

Philippe, do we really need these ugly PIC patches?

Not anymore, since we decided to stop supporting a tortuous use case
where some IRQ channel could be shared between a Xenomai ISR and a Linux
handler for handling mixed RT/non-RT devices (which was something of a
bugous design anyway). Doing so, the patch was about preventing
IRQ_INPROGRESS to block IRQ reenabling requests issued from a Xenomai
ISR (i.e. in case a RT interrupt preempts the regular Linux handler for
the same IRQ channel).

The problem I see now, is that removing the work-arounds from the
various PIC code would void the ability to use recent Adeos patches with
older Xenomai releases. I'm not opposed to that, provided we backport
your fix to 2.1.x and above, but this is an issue we should keep in
mind. Perhaps the next Adeos patches should even make un-fixed Xenomai
releases choke at compilation time.

We could also set the relevant status field bits to 0 somewhere in the IPIPE-patch when the IRQ is requested or overtaken. I think this is a general issue (not only on PowerPC).


Xenomai-core mailing list

Reply via email to