MPC83xx ipic problem
André Schwarz
andre.schwarz at matrix-vision.de
Tue Jul 1 01:34:01 EST 2008
Scott,
actually I'm having trouble with my PCI interrupts.
We are running 2.6.26-rc6 on a MPC8343 based board.
There are two external PCI devices connected (FPGA + miniPCI socket).
The FPGA is working fine and uses IRQ0 for its PCI_INTA line.
As soon there's a miniPCI module present and the driver loaded (actually
an ath5k WiFi module) the system complains after a while :
irq 48: nobody cared
handlers: .... location of the FPGA irq handler
Disabling IRQ #48
-> This is weird since the FPGA isn't working at all and IRQ0 is *not*
asserted !
Of course the miniPCI irq is routed to a different pin on the CPU
(IRQ1). Having a look at the irq count it's obvious that the WiFi irqs
are handled (ath module). The FPGA irq handler is located in the
"mvbcdma0" module which is running rock solid without miniPCI present !
mvBL-M7> cat /proc/interrupts
CPU0
16: 1826 IPIC Level i2c-mpc
17: 9 IPIC Level i2c-mpc
18: 201 IPIC Level ath
19: 2896 IPIC Level serial
21: 0 IPIC Level mpc83xx_spi
32: 2 IPIC Level enet_tx
33: 257 IPIC Level enet_rx
34: 0 IPIC Level enet_error
48: 100000 IPIC Level mvbcdma0
BAD: 0
The irq mapping insides the dts :
interrupt-map = <0x5800 0 0 1 &ipic 0x30 0x8 -> FPGA @ IRQ0
0x6000 0 0 1 &ipic 0x11 0x8 -> miniPCI INTA @ IRQ1
0x6000 0 0 2 &ipic 0x11 0x8>; -> miniPCI INTB @ IRQ1
Is it legal to use a single irq pin twice ?
After all the ath5k doesn't use/assert the INTB line at all ...
If I do all the above after removing the FPGA module and releasing irq48
the system doesn't complain anymore ... but hangs after a while with the
IRQ1 line being unserviced.
What do you think ?
Any hints ?
Am I doing anything obviously wrong ?
regards,
André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
More information about the Linuxppc-dev
mailing list