RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Steve DeLaney]

 

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

RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Timur Tabi]

On Tue, Mar 3, 2009 at 11:39 PM, Steve DeLaney <onramp123@yahoo.com> 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

Re: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Grant Likely]

On Tue, Mar 3, 2009 at 10:39 PM, Steve DeLaney <onramp123@yahoo.com> 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.

Re: Can't load module spi_mpc83xx : No such device

[Anton Vorontsov]

On Fri, Feb 27, 2009 at 03:56:41PM +1100, Dushara Jayasinghe wrote:
> Hi all,
> 
> I'm using linux version 2.6.29-rc5.

Linus' tree is still lacking few patches for spi_mpc83xx driver, the
patches makes spi_mpc83xx work with the device tree directly.

You should use -mm kernels.

[...]
> Part of my device tree is as follows:
> 
> 	soc8349@e0000000 {
> 		...
> 		spi@7000 {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			compatible = "fsl,spi";
> 			reg = <0x7000 0x1000>;
> 			interrupts = <0x10 0x8>;
> 			interrupt-parent = < &ipic >;

You don't seem to have any chip-selects (i.e. gpios = <>) specified.

If the chip-select is always asserted (i.e. there is only one
device on the SPI bus), then..

> 
> 			m25p40@2 {
> 				compatible = "m25p80";
> 				spi-max-frequency = <25000000>;
> 				reg = <2>;

..there is no point in specifying reg = <> for the device.


Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

mpc8349e-mitx 2.6.25 serial IRQ assigned wrong

[Steve DeLaney]

 
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