linux-mips
[Top] [All Lists]

Re: Xtalk bridge IRQs

To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Subject: Re: Xtalk bridge IRQs
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 24 Apr 2004 20:19:59 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.GSO.4.10.10404241914160.10450-100000@helios.et.put.poznan.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.GSO.4.10.10404241914160.10450-100000@helios.et.put.poznan.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Sat, Apr 24, 2004 at 07:14:32PM +0200, Stanislaw Skowronek wrote:

> I've got a problem with Xtalk-PCI bridge IRQs. The IOC3 should send an
> interrupt before transmitting a packet. I don't know if it sends it or
> not, but for sure it does not arrive to me. The power button interrupt,
> which is also routed via the bridge, works OK, so the IRQ router part of
> the bridge is correctly services. However, I can't get any PCI interrupts.

The way that PCI interrupts work on IP27 is: A device's INTA pin is
connected to the BRIDGE ASIC.  When a device's interrupt line is asserted,
the bridge ASIC will store a value which consists of 0x100 | intnum into
another register; the address of that other register can be configured per
device in the BRIDGE chip.  The value is usuall the xtalk address of another
register in the HUB ASIC.  For HUB the value 0x100 | intnum would mean to
set bit intnum in the interrupt pending register.  The BRIDGE chip
can also be configured to send an interrupt clear packet if the PCI
interrupt is deasserted again; it's a good idea to have this enabled since
otherwise writing race-free interrupt handlers is a PITA.  The HUB
chip then asserts one of the CPU interrupt lines if a bit is set in the
interrupt pending register and mask0/mask1 register for the CPU.

For a single node system this could be slightly simplified - no idea if
SGI did that for the HEART design.  Anyway, in case of an Origin you'd
have to chase the interrupt through the various stages of processing:

 - Interupt sent from the device?
 - Interrupt asserted at BRIDGE?
 - Interrupt bit set in HUB chip?
 - Interrupt enabled in HUB mask register?
 - Interrupt pending in the CPU's cause register?
 - Interrupt bit set and EXL and ERL both clear in CPU status register?

I hope that's somehow applicable to the IP30 ...

  Ralf

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