RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

 

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

On Tue, 2009-03-03 at 21:39 -0800, Steve DeLaney wrote:

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.

I'm not clear on what the problem is.

The interrupt numbers in /proc/interrupts will no longer match what the
old kernel had, because as you mention the values in /proc/interrupts
are virtual irqs.

If you want to see the mapping turn on CONFIG_VIRQ_DEBUG and you'll get
a file in debugfs called virq_mapping that shows the details.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

On Tue, Mar 3, 2009 at 11:39 PM, Steve DeLaney [off-list ref] wrote:

For the mpc8349e-mitx this must be incorrect since there is no ISA?

That doesn't matter.  We want the code to be as common as possible.
The actual virtual IRQ value is irrelevant.  The OF code gives you a
virq number, and you just use that.  Any code or board design that
depends on any relationship between the virq and the hwirq is broken.

Essentially all that is needed is a 1:1 mapping hirq:virq since

Needed for who?

For now we simply define irq.h NUM_ISA_INTERRUPTS 0

This is a bad idea.  You will just break something else.

-- 
Timur Tabi
Linux kernel developer at Freescale

On Tue, Mar 3, 2009 at 10:39 PM, Steve DeLaney [off-list ref] wrote:

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. =A0It seems this scheme is needlessly complex, at least =

for

mpc8349e.

It may look to be needlessly complex for boards that only have one
interrupt controller, but it is far simpler than the alternative when
you have boards with multiple cascaded IRQ controllers.  This is not
an uncommon circumstance any more, even on embedded boards.  ie. I'm
working on two different MPC5200 platforms and each has an FPGA which
coalesces interrupts to a single MPC5200 external IRQ line.

Without VIRQs, I'd need to slice up the IRQ number space for each
board variant I work with and write the code to match.  With VIRQs,
there is no need to, and all of the boards can use common support
code.

g.
.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.