Grabbing an Interrupt for a Brain-dead PCI Device

So, unfortunately, I didn't do the design for this "dumb" PCI device and
neither can I fix its shortcomings in these regards.

Below, we've acknowledged and discovered how to sort of work-around the
problem of the invalid vendor ID and the base address. Now, I've yet
another problem.

The device has an interrupt at INTA#. Unfortunately, the device being dumb
as it is, doesn't utilize the interrupt pin register to advertise that it
does in fact have an interrupt there. So, I assume that once again, the
PROM doesn't give it one.

Is there a way, in Linux, for me to programmatically and manually assign
an interrupt to this device as might have been done in the PROM? I'm
guessing I have to twiddle some registers in the North Bridge, correct?

Thanks,

Grant


On Mon, 6 Mar 2000, Geert Uytterhoeven wrote:

On Sun, 5 Mar 2000, Grant Erickson wrote:

quoted

After modifying the Linux kernel to accept PCI devices with the invalid
vendor/device ID combination of 0xffff/0x0000, I noticed something odd
about the way the system PROM (and to a lesser extent Linux) configured
the chip's base addresses. Looking at a number of other devices in the
system:

        grant@marathon% cat /proc/iomem
        81800000-8180001f : PCI device 1022:2000 AMD Lance Ethernet
        81900000-819fffff : PCI device 1022:2000 AMD Lance Ethernet
        82000000-82ffffff : PCI device 1002:4754 ATI Mach 128
        f3000000-f307ffff : PCI device 106b:0010 Apple Heathrow I/O
        fffc0000-ffffffff : PCI device ffff:0000 ???

Clue 1: The address range programmed for the chip looks suspiciously like
the state it might be left in after determining how much address space it
needs.

Yes.

quoted

Before Linux does this address space sizing, it saves the base address.
In the case of my chip, it would have read "0x0" since nothing was
programmed there previously. If Linux does find 0x0, it just leaves the
result of the address sizing there and moves on.

So, that led me to wonder where the addresses in the other devices were
coming from...

I found that even before Linux executes a single line of code, all the
other devices above have valid addresses programmed into their base
address registers. Who's doing this?

I believe that the Open Firmware PROM in the PowerPC system probes all
PCI devices in the system at power up. It then assigns valid base
addresses to those devices with VALID vendor and device IDs.

OF (should) assign addresses. On my box (CHRP), it does so for _recognized_
devices only.

quoted

Because my chip uses an invalid vendor ID of 0xFFFF, Open Firmware must
just ignore it and never programs in a valid base address! Therefore,
when we go and try to access the chip at 0xFFFC0000 (which is outside the
valid PCI address space on PReP/CHRP/PowerMac systems?) we're off probing
never-never land. The PCI controller never assumes the transaction!

How difficult is it to make the PCI chip use a valid vendor/device ID? I don't
think you can assume any boot ROM will try to assign a region to it. There's no
way to distinguish a device with an invalid vendor/device ID from a device
that's not even present.

Go read the PCI spec and use valid IDs.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/