From: "Steve DeLaney" <onramp123@yahoo.com>
To: <linuxppc-dev@ozlabs.org>
Subject: RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
Date: Tue, 3 Mar 2009 21:39:19 -0800 [thread overview]
Message-ID: <025a01c99c8b$90afb030$6b03a8c0@sdelaney2> (raw)
In-Reply-To:
Here's an update on this issue.
After verifying the device tree was OK, the OF traces led us to the root
cause.
powerpc irq.c irq_alloc_virt() assigns a virtual IRQ as a function of the
input hardware IRQ hint, AND NUM_ISA_INTERRUPTS. it turns out that
asm-ppc/irq.h defines NUM_ISA_INTERRUPTS 16, so that the allocated virq
is offset by this amount. this accounts for the remap shown below for
i2c and serial device vectors.
I didn't realize before that /proc/interrupts
serviced by irq.c show_interrupts() displays virtual vector numbers.
For the mpc8349e-mitx this must be incorrect since there is no ISA?
Essentially all that is needed is a 1:1 mapping hirq:virq since
each interrupt source in the system appears to have a unique vector
in the SOC IPIC. It seems this scheme is needlessly complex, at least for
mpc8349e.
For now we simply define irq.h NUM_ISA_INTERRUPTS 0
but this isn't a complete solution since our PCI device
interrupt on hirq 20, ends up allocated on virq 1. To force
this to work, the driver does an irq_create_mapping(NULL, 20),
then assigns its own dev->irq=20 before calling request_irq()
I'm sure someone has a more elegant solution but that's what
we've been able to come up with so far.
/steverino2
-----Original Message-----
From: Steve DeLaney [mailto:onramp123@yahoo.com]
Sent: Saturday, February 28, 2009 8:08 AM
To: 'linuxppc-dev@ozlabs.org'
Subject: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
Hello all,
We completed a 2.6.25 build for MPC8349E-mITX platform, and u-booting using
the device tree under ...boot/dts/mpc8349emitx.dts
But the standard platform device IRQs are assigned wrong under
/proc/interrupts:
16 i2c-mpc
17 i2c-mpc
20 serial
According to the device tree, and the processor data sheet, it should be
like this:
9 serial
14 i2c-mpc
15 i2c-mpc
earlier builds (pre-dating device tree) of 2.6.13 and 2.6.16 are OK.
The IRQs are assigned correctly, with serial on 9.
Oddly enough the serial port works OK even though it is assigned to IRQ 20.
We could probably live with it, but this interferes with our application
that uses PCI.
On MPC8349E-mITX, PIC IRQ 20 is intended for PCI INTA that is input to the
MPC8349E processor on IRQ4* signal.
We turned on debug output in irq.c and prom_parse.c Any idea what might be
going wrong? We would appreciate any suggestions on what to look for.
/steverino2
next reply other threads:[~2009-03-04 5:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 5:39 Steve DeLaney [this message]
2009-03-04 13:00 ` mpc8349e-mitx 2.6.25 serial IRQ assigned wrong Michael Ellerman
2009-03-04 22:21 ` Timur Tabi
2009-03-04 23:08 ` Grant Likely
-- strict thread matches above, loose matches on Subject: below --
2009-02-27 12:54 Can't load module spi_mpc83xx : No such device Anton Vorontsov
2009-02-28 16:07 ` mpc8349e-mitx 2.6.25 serial IRQ assigned wrong Steve DeLaney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='025a01c99c8b$90afb030$6b03a8c0@sdelaney2' \
--to=onramp123@yahoo.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).