On Wed, 2006-09-13 at 12:34 +0200, Wolfgang Grandegger wrote:
> 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.
> >>>>
> >>>> Wolfgang.
> >>>>
> >>> 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).

This would not clear the issue for IRQ_INPROGRESS, which is raised upon
IRQ handling.

> 
> Wolfgang.
> 
> 
-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to