Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405

[Wolfgang Grandegger <wg@domain.hid>]

Philippe Gerum wrote:
> 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.

Ok, should I fix that and remove all PowerPC PIC patches already for the 
Adeos iPipe PPC patch for 2.6.18rc6 I'm currently working on?

Wolfgang.