Re: [Xenomai-core] external hardware interupts on a PPC405
On Monday 11 September 2006 06:46, Philipp Keller wrote: We are using ppc6xx, but hat a timing problem with external HW, perhaps this is related to that interrupt thing? We saw on the oszilloscope that we have to init the rtcan with half the baudrate the external modules use, then it works. Philipp It is true that you have to pass the clock frequency divided by two to the rtcan drivers. This is discussed in a separate thread (see CAN updates questions). My problem is propably not related to the rtcan drivers because sending and receiving a single message always works fine. Matthias ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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=0xf000 irq=25
rtcan: registered rtcan0
_enable: ER=003f0040, SR=c000
2) receiving
bash-3.00# /sbin/rtcanconfig rtcan0 -b 50 up
bash-3.00# ./bin/rtcanrecv rtcan0
_ack: ER=003f, SR=c040
_end: ER=003f, SR=c000
#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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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=0xf000 irq=25
rtcan: registered rtcan0
_enable: ER=003f0040, SR=c000
2) receiving
bash-3.00# /sbin/rtcanconfig rtcan0 -b 50 up
bash-3.00# ./bin/rtcanrecv rtcan0
_ack: ER=003f, SR=c040
_end: ER=003f, SR=c000
#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.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c2006-09-11 12:18:14.0 +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@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c 2006-09-11 12:18:14.0 +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]); \
} \
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c2006-09-11 12:18:14.0 +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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c 2006-09-11 12:18:14.0 +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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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.0
+0200
+++ arch/ppc/syslib/ppc4xx_pic.c 2006-09-11 12:18:14.0 +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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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.0 +0200
+++ arch/ppc/syslib/ppc4xx_pic.c2006-09-11 12:18:14.0 +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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
So it's IRQ_DISABLED (=2).
Matthias
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] No hardware interrupts with xenomai on ppc405
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=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
bash-3.00# ./bin/rtcansend rtcan0 -i 0 1 2 3 4
_end: status=0042
So it's IRQ_DISABLED (=2).
In 2.6 the interrupts are disabled by default. Then the attached patch
for Xenomai should help.
Wolfgang.
+ 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.0 +0200
+++ xenomai/ksrc/arch/powerpc/hal.c 2006-09-11 20:00:32.0 +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;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
