linux-mips
[Top] [All Lists]

Re: Interrupt routing issue on BCM1480.

To: Kaz Kylheku <KKylheku@zeugmasystems.com>
Subject: Re: Interrupt routing issue on BCM1480.
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 18 Nov 2008 22:28:20 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <DDFD17CC94A9BD49A82147DDF7D545C50144C3F0@exchange.ZeugmaSystems.local>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <DDFD17CC94A9BD49A82147DDF7D545C50144C3F0@exchange.ZeugmaSystems.local>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Nov 18, 2008 at 02:00:08PM -0800, Kaz Kylheku wrote:

> Ralf's fixes in arch/mips/pci/pci-bcm1480.c break on our board. Multiple
> devices somehow report the same pin number (or perhaps some invalid pin
> number that is mapped to 1).  The mapping function then assigns IRQ 8 to
> multiple devices.

That's fine.  A simple PCI device that uses an interrupt is supposed to
use INTA that is report a 1 in the interrupt pin register.  After going
through any PCI-to-PCI bridges (if they exist), INTA..INTD eventually
will be wired in a system specific way to the host.  For the BCM91480
that wiring seems to be to simply wire (or "or") all INTA pins together
and connect that signal to the SOC, same for the remaining INTB..INTD.
In practice this means it is expected to see most PCI devices to use
K_BCM1480_INT_PCI_INTA which is 8.  I suppose your system may wire up
things in a different way and CFE knows about that but not pcibios_map_irq().

> The old ``return dev->irq'' in pcibios_map_irq worked fine.
> 
> What was the issue: is it that CFE sets up these IRQ numbers, such that
> they might not correspond to pins?

Linux interrupt number is not necessarily the same as that of any
firmware, so relying on firmware is generally wrong or at least
something only to be done if you know what you do ...

  Ralf

<Prev in Thread] Current Thread [Next in Thread>