mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Michael Ellerman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090305/881dfeeb/attachment.pgp>