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

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

[Matthias Fuchs]

Hi,

I was trying to use some external hardware interupts on a PPC405 board
as part of a hacking session with Jan to bring up the rtcan driver on
this board.

Here are some versions:

	Linux Kernel: 2.6.14
	Adeos: 1.3-07
	Xenomai: from svn (2.3pre, last friday night)

The first interrupt interrupt was always fine. When the 2nd interupt
occured, it was never handled and did not cause any action. We used the
ipipe-tracer and did not see anything related to the 2nd and any further
interrupt.

I think that the hardware interrupt is somehow masked and therefore
never result in any action. So the handling of the first interrupt might
be incorrect.

This seems to be ppc or even ppc4xx related because I assume that x86
platforms do not have this issue. Is this an Adeos issue.

I will do the same test on a 2.4 kernel next week - if nobody tells me
that this will be a waste of time.

Matthias

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

[Wolfgang Grandegger]

Hi Matthias,

Matthias Fuchs wrote:
> Hi,
> 
> I was trying to use some external hardware interupts on a PPC405 board
> as part of a hacking session with Jan to bring up the rtcan driver on
> this board.
> 
> Here are some versions:
> 
> 	Linux Kernel: 2.6.14
> 	Adeos: 1.3-07
> 	Xenomai: from svn (2.3pre, last friday night)
> 
> The first interrupt interrupt was always fine. When the 2nd interupt
> occured, it was never handled and did not cause any action. We used the
> ipipe-tracer and did not see anything related to the 2nd and any further
> interrupt.
> 
> I think that the hardware interrupt is somehow masked and therefore
> never result in any action. So the handling of the first interrupt might
> be incorrect.
> 
> This seems to be ppc or even ppc4xx related because I assume that x86
> platforms do not have this issue. Is this an Adeos issue.
> 
> I will do the same test on a 2.4 kernel next week - if nobody tells me
> that this will be a waste of time.

Could you please add printk statements to the ack, enable and end 
functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches. 
Please print also SR, ER and status.

Wolfgang.

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

[Matthias Fuchs]

On Sunday 10 September 2006 13:02, Wolfgang Grandegger wrote:
> Hi Matthias,
> 
> Matthias Fuchs wrote:
> > Hi,
> > 
> > I was trying to use some external hardware interupts on a PPC405 board
> > as part of a hacking session with Jan to bring up the rtcan driver on
> > this board.
> > 
> 
> Could you please add printk statements to the ack, enable and end 
> functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches. 
> Please print also SR, ER and status.

1) insmodding the driver:
bash-3.00# modprobe xeno_rtcan_isa mem=0xf0000000 irq=25
rtcan: registered rtcan0
_enable: ER=003f0040, SR=c0000000

2) receiving
bash-3.00# /sbin/rtcanconfig rtcan0 -b 500000 up
bash-3.00# ./bin/rtcanrecv rtcan0
_ack: ER=003f0000, SR=c0000040
_end: ER=003f0000, SR=c0000000
#0: (1) <0x000> [8] 00 00 00 00 01 00 00 00

That's it. When sending a 2nd message to the board, nothing happens. 
We have a LED on the SJA1000 interrupt signal. After sending the 2nd message 
this LED stays on, so the interrupt is never handled.

It seems that the interrupt is not reenabled (bit 25) in the "end" function.

Matthias

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

[Wolfgang Grandegger]

Matthias Fuchs wrote:
> On Sunday 10 September 2006 13:02, Wolfgang Grandegger wrote:
>> Hi Matthias,
>>
>> Matthias Fuchs wrote:
>>> Hi,
>>>
>>> I was trying to use some external hardware interupts on a PPC405 board
>>> as part of a hacking session with Jan to bring up the rtcan driver on
>>> this board.
>>>
>> Could you please add printk statements to the ack, enable and end 
>> functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches. 
>> Please print also SR, ER and status.
> 
> 1) insmodding the driver:
> bash-3.00# modprobe xeno_rtcan_isa mem=0xf0000000 irq=25
> rtcan: registered rtcan0
> _enable: ER=003f0040, SR=c0000000
> 
> 2) receiving
> bash-3.00# /sbin/rtcanconfig rtcan0 -b 500000 up
> bash-3.00# ./bin/rtcanrecv rtcan0
> _ack: ER=003f0000, SR=c0000040
> _end: ER=003f0000, SR=c0000000
> #0: (1) <0x000> [8] 00 00 00 00 01 00 00 00

OK. I will lookup the meaning later today.

> That's it. When sending a 2nd message to the board, nothing happens. 
> We have a LED on the SJA1000 interrupt signal. After sending the 2nd message 
> this LED stays on, so the interrupt is never handled.
> 
> It seems that the interrupt is not reenabled (bit 25) in the "end" function.

Could you please add a printout of status. It's important that the 
following if statement is entered in the end function:


	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {
                 ppc_cached_irq_mask[n] |= mask;
                 mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);
         }


And could you also try replacing all lines

         if (status & IRQ_LEVEL) { 


with

         if (status & IRQ_LEVEL || irq == <your-irq>) { 


Thanks.

Wolfgang.

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

[Philippe Gerum]

On Mon, 2006-09-11 at 10:58 +0200, Matthias Fuchs wrote:
> On Sunday 10 September 2006 13:02, Wolfgang Grandegger wrote:
> > Hi Matthias,
> > 
> > Matthias Fuchs wrote:
> > > Hi,
> > > 
> > > I was trying to use some external hardware interupts on a PPC405 board
> > > as part of a hacking session with Jan to bring up the rtcan driver on
> > > this board.
> > > 
> > 
> > Could you please add printk statements to the ack, enable and end 
> > functions to arch/ppc/syslib/ppc4xx_pic.c if the irq number matches. 
> > Please print also SR, ER and status.
> 
> 1) insmodding the driver:
> bash-3.00# modprobe xeno_rtcan_isa mem=0xf0000000 irq=25
> rtcan: registered rtcan0
> _enable: ER=003f0040, SR=c0000000
> 
> 2) receiving
> bash-3.00# /sbin/rtcanconfig rtcan0 -b 500000 up
> bash-3.00# ./bin/rtcanrecv rtcan0
> _ack: ER=003f0000, SR=c0000040
> _end: ER=003f0000, SR=c0000000
> #0: (1) <0x000> [8] 00 00 00 00 01 00 00 00
> 
> That's it. When sending a 2nd message to the board, nothing happens. 
> We have a LED on the SJA1000 interrupt signal. After sending the 2nd message 
> this LED stays on, so the interrupt is never handled.
> 
> It seems that the interrupt is not reenabled (bit 25) in the "end" function.
> 

It's likely an Adeos issue. Could you try this patch? TIA,

--- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
@@ -72,7 +72,8 @@
 		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
 		ACK_UIC##n##_PARENT					\
 	}								\
-	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
+	if (!ipipe_root_domain_p ||					\
+	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
 		ppc_cached_irq_mask[n] |= mask;				\
 		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
 	}								\

> Matthias
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

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

[Matthias Fuchs]

Hello Philippe,

that helps. I will do some further testing.

Matthias


On Monday 11 September 2006 12:20, Philippe Gerum wrote:
> It's likely an Adeos issue. Could you try this patch? TIA,
> 
> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
> @@ -72,7 +72,8 @@
>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
>  		ACK_UIC##n##_PARENT					\
>  	}								\
> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
> +	if (!ipipe_root_domain_p ||					\
> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>  		ppc_cached_irq_mask[n] |= mask;				\
>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
>  	}								\

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

[Wolfgang Grandegger]

Matthias Fuchs wrote:
> Hello Philippe,
> 
> that helps. I will do some further testing.
> 
> Matthias
> 
> 
> On Monday 11 September 2006 12:20, Philippe Gerum wrote:
>> It's likely an Adeos issue. Could you try this patch? TIA,
>>
>> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
>> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
>> @@ -72,7 +72,8 @@
>>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
>>  		ACK_UIC##n##_PARENT					\
>>  	}								\
>> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>> +	if (!ipipe_root_domain_p ||					\
>> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>>  		ppc_cached_irq_mask[n] |= mask;				\
>>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
>>  	}								\
> 

Philippe, could you please explain the problem in more detail? And what 
are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?

Thanks.

Wolfgang.

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

[Philippe Gerum]

On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
> > Hello Philippe,
> > 
> > that helps. I will do some further testing.
> > 
> > Matthias
> > 
> > 
> > On Monday 11 September 2006 12:20, Philippe Gerum wrote:
> >> It's likely an Adeos issue. Could you try this patch? TIA,
> >>
> >> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
> >> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
> >> @@ -72,7 +72,8 @@
> >>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
> >>  		ACK_UIC##n##_PARENT					\
> >>  	}								\
> >> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
> >> +	if (!ipipe_root_domain_p ||					\
> >> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
> >>  		ppc_cached_irq_mask[n] |= mask;				\
> >>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
> >>  	}								\
> > 
> 
> Philippe, could you please explain the problem in more detail? And what 
> are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?

The issue lies in the fact that PICs *_end() routines may be called over
the Xenomai domain, and actually are, most of the time, since
xnintr_irq_handler() -which invokes xnarch_end_irq()- is always called
from the the Xenomai stage in the Adeos pipeline.

In such a case, we must not check for the Linux-defined IRQ bits (e.g.
IRQ_INPROGRESS), and always send the eoi, since those bits are not
relevant to the Xenomai context. The patch above ensures this.

And yes, the 2.4 patch has the very same problem, which should be fixed
the same way for all supported ppc platforms in the various PIC
management code. Oops.

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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

Philippe Gerum wrote:
> On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
>> Matthias Fuchs wrote:
>>> Hello Philippe,
>>>
>>> that helps. I will do some further testing.
>>>
>>> Matthias
>>>
>>>
>>> On Monday 11 September 2006 12:20, Philippe Gerum wrote:
>>>> It's likely an Adeos issue. Could you try this patch? TIA,
>>>>
>>>> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
>>>> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
>>>> @@ -72,7 +72,8 @@
>>>>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
>>>>  		ACK_UIC##n##_PARENT					\
>>>>  	}								\
>>>> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>>>> +	if (!ipipe_root_domain_p ||					\
>>>> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>>>>  		ppc_cached_irq_mask[n] |= mask;				\
>>>>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
>>>>  	}								\
>> Philippe, could you please explain the problem in more detail? And what 
>> are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?
> 
> The issue lies in the fact that PICs *_end() routines may be called over
> the Xenomai domain, and actually are, most of the time, since
> xnintr_irq_handler() -which invokes xnarch_end_irq()- is always called
> from the the Xenomai stage in the Adeos pipeline.
> 
> In such a case, we must not check for the Linux-defined IRQ bits (e.g.
> IRQ_INPROGRESS), and always send the eoi, since those bits are not
> relevant to the Xenomai context. The patch above ensures this.
> 
> And yes, the 2.4 patch has the very same problem, which should be fixed
> the same way for all supported ppc platforms in the various PIC
> management code. Oops.

And why didn't this render PPC-over-2.4 useless, i.e. what is special
about this 405-scenario?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

On Mon, 2006-09-11 at 16:22 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
> >> Matthias Fuchs wrote:
> >>> Hello Philippe,
> >>>
> >>> that helps. I will do some further testing.
> >>>
> >>> Matthias
> >>>
> >>>
> >>> On Monday 11 September 2006 12:20, Philippe Gerum wrote:
> >>>> It's likely an Adeos issue. Could you try this patch? TIA,
> >>>>
> >>>> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
> >>>> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
> >>>> @@ -72,7 +72,8 @@
> >>>>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
> >>>>  		ACK_UIC##n##_PARENT					\
> >>>>  	}								\
> >>>> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
> >>>> +	if (!ipipe_root_domain_p ||					\
> >>>> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
> >>>>  		ppc_cached_irq_mask[n] |= mask;				\
> >>>>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
> >>>>  	}								\
> >> Philippe, could you please explain the problem in more detail? And what 
> >> are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?
> > 
> > The issue lies in the fact that PICs *_end() routines may be called over
> > the Xenomai domain, and actually are, most of the time, since
> > xnintr_irq_handler() -which invokes xnarch_end_irq()- is always called
> > from the the Xenomai stage in the Adeos pipeline.
> > 
> > In such a case, we must not check for the Linux-defined IRQ bits (e.g.
> > IRQ_INPROGRESS), and always send the eoi, since those bits are not
> > relevant to the Xenomai context. The patch above ensures this.
> > 
> > And yes, the 2.4 patch has the very same problem, which should be fixed
> > the same way for all supported ppc platforms in the various PIC
> > management code. Oops.
> 
> And why didn't this render PPC-over-2.4 useless, i.e. what is special
> about this 405-scenario?
> 

A possible explanation is that configurations only using the timer IRQ
are not affected, since the decrementer is not subject to this issue
(the tick handler returns XN_ISR_NOENABLE anyway).

-- 
Philippe.

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

[Wolfgang Grandegger]

Philippe Gerum wrote:
> On Mon, 2006-09-11 at 16:22 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
>>>> Matthias Fuchs wrote:
>>>>> Hello Philippe,
>>>>>
>>>>> that helps. I will do some further testing.
>>>>>
>>>>> Matthias
>>>>>
>>>>>
>>>>> On Monday 11 September 2006 12:20, Philippe Gerum wrote:
>>>>>> It's likely an Adeos issue. Could you try this patch? TIA,
>>>>>>
>>>>>> --- arch/ppc/syslib/ppc4xx_pic.c~	2005-10-28 02:02:08.000000000 +0200
>>>>>> +++ arch/ppc/syslib/ppc4xx_pic.c	2006-09-11 12:18:14.000000000 +0200
>>>>>> @@ -72,7 +72,8 @@
>>>>>>  		mtdcr(DCRN_UIC_SR(UIC##n), mask);			\
>>>>>>  		ACK_UIC##n##_PARENT					\
>>>>>>  	}								\
>>>>>> -	if (!(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>>>>>> +	if (!ipipe_root_domain_p ||					\
>>>>>> +	    !(status & (IRQ_DISABLED | IRQ_INPROGRESS))) {		\
>>>>>>  		ppc_cached_irq_mask[n] |= mask;				\
>>>>>>  		mtdcr(DCRN_UIC_ER(UIC##n), ppc_cached_irq_mask[n]);	\
>>>>>>  	}								\
>>>> Philippe, could you please explain the problem in more detail? And what 
>>>> are the consequences for other PowerPC ARCs and PICs, also for Linux 2.4?
>>> The issue lies in the fact that PICs *_end() routines may be called over
>>> the Xenomai domain, and actually are, most of the time, since
>>> xnintr_irq_handler() -which invokes xnarch_end_irq()- is always called
>>> from the the Xenomai stage in the Adeos pipeline.
>>>
>>> In such a case, we must not check for the Linux-defined IRQ bits (e.g.
>>> IRQ_INPROGRESS), and always send the eoi, since those bits are not
>>> relevant to the Xenomai context. The patch above ensures this.
>>>
>>> And yes, the 2.4 patch has the very same problem, which should be fixed
>>> the same way for all supported ppc platforms in the various PIC
>>> management code. Oops.
>> And why didn't this render PPC-over-2.4 useless, i.e. what is special
>> about this 405-scenario?
>>
> 
> A possible explanation is that configurations only using the timer IRQ
> are not affected, since the decrementer is not subject to this issue
> (the tick handler returns XN_ISR_NOENABLE anyway).

I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any 
problems, so far (under Linux 2.4). Here the end function of the PIC:

   static void
   mpc5xxx_ic_end(unsigned int irq)
   {
         if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
                 mpc5xxx_ic_enable(irq);
   }

Matthias, have you printed out the value of status? I'm just curious.

Wolfgang.

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

[Matthias Fuchs]

On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
> > 
> > A possible explanation is that configurations only using the timer IRQ
> > are not affected, since the decrementer is not subject to this issue
> > (the tick handler returns XN_ISR_NOENABLE anyway).
> 
> I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any 
> problems, so far (under Linux 2.4). Here the end function of the PIC:
> 
>    static void
>    mpc5xxx_ic_end(unsigned int irq)
>    {
>          if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
>                  mpc5xxx_ic_enable(irq);
>    }
> 
> Matthias, have you printed out the value of status? I'm just curious.
> 
> Wolfgang.

Here it comes:
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=00000042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=00000042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=00000042

So it's IRQ_DISABLED (=2).

Matthias

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

[Wolfgang Grandegger]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Matthias Fuchs wrote:
> On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
>>> A possible explanation is that configurations only using the timer IRQ
>>> are not affected, since the decrementer is not subject to this issue
>>> (the tick handler returns XN_ISR_NOENABLE anyway).
>> I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any 
>> problems, so far (under Linux 2.4). Here the end function of the PIC:
>>
>>    static void
>>    mpc5xxx_ic_end(unsigned int irq)
>>    {
>>          if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
>>                  mpc5xxx_ic_enable(irq);
>>    }
>>
>> Matthias, have you printed out the value of status? I'm just curious.
>>
>> Wolfgang.
> 
> Here it comes:
> bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> _end: status=00000042
> bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> _end: status=00000042
> bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> _end: status=00000042
> 
> So it's IRQ_DISABLED (=2).

In 2.6 the interrupts are disabled by default. Then the attached patch 
for Xenomai should help.

Wolfgang.

[-- Attachment #2: xenomai-irqend.patch --]
[-- Type: text/x-patch, Size: 675 bytes --]

+ diff -u xenomai/ksrc/arch/powerpc/hal.c.IRQEND xenomai/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c.IRQEND	2006-08-23 22:12:17.000000000 +0200
+++ xenomai/ksrc/arch/powerpc/hal.c	2006-09-11 20:00:32.000000000 +0200
@@ -326,6 +326,7 @@
         rthal_irq_descp(irq)->handler->enable == NULL)
         return -ENODEV;
 
+    rthal_irq_descp(irq)->status &= ~IRQ_DISABLED;
     rthal_irq_descp(irq)->handler->enable(irq);
 
     return 0;
@@ -341,6 +342,7 @@
         rthal_irq_descp(irq)->handler->disable == NULL)
         return -ENODEV;
 
+    rthal_irq_descp(irq)->status |= IRQ_DISABLED;
     rthal_irq_descp(irq)->handler->disable(irq);
 
     return 0;

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

[Matthias Fuchs]

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.

Matthias

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

[Wolfgang Grandegger]

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?

Wolfgang.

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

[Philippe Gerum]

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.

> 
> Wolfgang.
-- 
Philippe.

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

[Wolfgang Grandegger]

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).

Wolfgang.

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

[Philippe Gerum]

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.

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

[Philippe Gerum]

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.

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

[Wolfgang Grandegger]

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.

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

[Philippe Gerum]

On Wed, 2006-09-13 at 14:38 +0200, Wolfgang Grandegger wrote:
> 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?
> 

I think so. I'm also going to apply the suggested fix to the Xenomai
HAL, so that new Xenomai revs will work over old Adeos patches, and the
other way around too. TIA,

> Wolfgang.
-- 
Philippe.

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

[Philippe Gerum]

On Wed, 2006-09-13 at 14:38 +0200, Wolfgang Grandegger wrote:
> 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?
> 

This is the way I fixed it for Adeos over ppc, so that I can apply the
same logic to all other supported archs:

--- kernel/ipipe/core.c	20 Jun 2006 17:15:23 -0000	1.28
+++ kernel/ipipe/core.c	13 Sep 2006 12:47:05 -0000
@@ -565,20 +565,22 @@
 	ipd->irqs[irq].acknowledge = acknowledge;
 	ipd->irqs[irq].control = modemask;
 
-	if (irq < NR_IRQS &&
-	    handler != NULL &&
-	    !ipipe_virtual_irq_p(irq) && (modemask & IPIPE_ENABLE_MASK) != 0) {
-		if (ipd != ipipe_current_domain) {
-			/* IRQ enable/disable state is domain-sensitive, so we may
-			   not change it for another domain. What is allowed
-			   however is forcing some domain to handle an interrupt
-			   source, by passing the proper 'ipd' descriptor which
-			   thus may be different from ipipe_current_domain. */
-			err = -EPERM;
-			goto unlock_and_exit;
-		}
+	if (irq < NR_IRQS && handler != NULL && !ipipe_virtual_irq_p(irq)) {
+		__ipipe_enable_irqdesc(irq);
 
-		__ipipe_enable_irq(irq);
+		if ((modemask & IPIPE_ENABLE_MASK) != 0) {
+			if (ipd != ipipe_current_domain) {
+				/* IRQ enable/disable state is domain-sensitive, so we may
+				   not change it for another domain. What is allowed
+				   however is forcing some domain to handle an interrupt
+				   source, by passing the proper 'ipd' descriptor which
+				   thus may be different from ipipe_current_domain. */
+				err = -EPERM;
+				goto unlock_and_exit;
+			}
+			
+			__ipipe_enable_irq(irq);
+		}
 	}
 
 	err = 0;
Index: include/asm-ppc/ipipe.h
===================================================================
RCS file: /var/cvs/adeos/ipipe/v2.6/common/include/asm-ppc/ipipe.h,v
retrieving revision 1.28
diff -u -r1.28 ipipe.h
--- include/asm-ppc/ipipe.h	10 Sep 2006 15:10:03 -0000	1.28
+++ include/asm-ppc/ipipe.h	13 Sep 2006 12:47:05 -0000
@@ -146,7 +146,9 @@
 
 #define __ipipe_check_platform()	do { } while(0)
 
-#define __ipipe_enable_irq(irq)		enable_irq(irq)
+#define __ipipe_enable_irqdesc(irq)	do { irq_desc[irq].status &= ~IRQ_DISABLED; } while(0)
+
+#define __ipipe_enable_irq(irq)	enable_irq(irq)
 
 #define __ipipe_disable_irq(irq)	disable_irq(irq)
 
> Wolfgang.
-- 
Philippe.

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

[Philippe Gerum]

On Mon, 2006-09-11 at 20:13 +0200, Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
> > On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
> >>> A possible explanation is that configurations only using the timer IRQ
> >>> are not affected, since the decrementer is not subject to this issue
> >>> (the tick handler returns XN_ISR_NOENABLE anyway).
> >> I run RT-Socket-CAN on a CAN PCI Card on my MPC5200 without any 
> >> problems, so far (under Linux 2.4). Here the end function of the PIC:
> >>
> >>    static void
> >>    mpc5xxx_ic_end(unsigned int irq)
> >>    {
> >>          if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
> >>                  mpc5xxx_ic_enable(irq);
> >>    }
> >>
> >> Matthias, have you printed out the value of status? I'm just curious.
> >>
> >> Wolfgang.
> > 
> > Here it comes:
> > bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> > _end: status=00000042
> > bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> > _end: status=00000042
> > bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
> > _end: status=00000042
> > 
> > So it's IRQ_DISABLED (=2).
> 
> In 2.6 the interrupts are disabled by default. Then the attached patch 
> for Xenomai should help.


Applied, thanks.

-- 
Philippe.