On Wed, 2006-09-13 at 13:36 +0200, Philippe Gerum wrote:
> 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.

I mean this would not fix all the use cases, but this would be
sufficient to solve the non-tortuous ones, I agree. So yes, IRQ_DISABLED
could just be cleared in ipipe_virtualize_irq_from(), and that should be
enough.

> 
> > 
> > Wolfgang.
> > 
> > 
-- 
Philippe.



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

Reply via email to