Status of PCI-PCI bridge on UMAX S900

Status of PCI-PCI bridge on UMAX S900

[jingai]

Hello, I am just curious if anyone is working on getting the PCI-PCI
bridge code working for the UMAX S900 (similar to 9500, but
obviously different enough to break the code).  The problem is this:
all cards not in slots 1-2 are assigned an IRQ of 1, which is
obviously wrong.  I'm not sure why slot 3 does not work, however,
unless the code just thinks the PCI bridge *is* slot 3 (which it does
appear to be that way).

If no one is currently attempting to fix it, but someone would like to,
here is all of the relevant info I can think of.  Thanks in advance for
any help.

Location of the pci bridge in /proc is:

/proc/device-tree/bandit/pci-bridge/AAPL,interrupts

colour:/home/jingai# lspci
00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev
03)
00:0d.0 Unknown mass storage controller: Promise Technology, Inc. 20267
(rev 02)
00:0e.0 USB Controller: OPTi Inc. 82C861 (rev 10)
00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21052 (rev 01)
00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
01:01.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE
01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 30)

colour:/home/jingai# lspci -vv
00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev
03)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 32, cache line size 08

00:0d.0 Unknown mass storage controller: Promise Technology, Inc. 20267
(rev 02)
        Subsystem: Promise Technology, Inc.: Unknown device 4d33
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 23
        Region 0: I/O ports at 2070 [size=8]
        Region 1: I/O ports at 2060 [size=4]
        Region 2: I/O ports at 2050 [size=8]
        Region 3: I/O ports at 2040 [size=4]
        Region 4: I/O ports at 2000 [size=64]
        Region 5: Memory at 88020000 (32-bit, non-prefetchable) [size=128K]
        Expansion ROM at 88010000 [disabled] [size=64K]
        Capabilities: [58] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0e.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
        Subsystem: OPTi Inc. 82C861
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
        Latency: 32, cache line size 08
        Interrupt: pin A routed to IRQ 24
        Region 0: Memory at 88000000 (32-bit, non-prefetchable) [size=4K]

00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21052 (rev 01)
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, cache line size 08
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 00001000-00001fff
        Memory behind bridge: 80800000-87ffffff
        BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
        Latency: 32, cache line size 08
        Region 0: Memory at f3000000 (32-bit, non-prefetchable) [size=128K]

01:01.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE
(prog-if 00 [VGA])
        Subsystem: Unknown device b530:0408
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min), cache line size 08
        Interrupt: pin A routed to IRQ 1
        Region 0: Memory at 84000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at 1000 [size=256]
        Region 2: Memory at 80804000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 80840000 [disabled] [size=128K]
        Capabilities: [5c] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 30)
        Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2500ns min, 2500ns max), cache line size 08
        Interrupt: pin A routed to IRQ 1
        Region 0: I/O ports at 1400 [size=128]
        Region 1: Memory at 80800000 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at 80820000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable+ DSel=0 DScale=2 PME-


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

Re: Status of PCI-PCI bridge on UMAX S900

[Benjamin Herrenschmidt]

>Hello, I am just curious if anyone is working on getting the PCI-PCI
>bridge code working for the UMAX S900 (similar to 9500, but
>obviously different enough to break the code).  The problem is this:
>all cards not in slots 1-2 are assigned an IRQ of 1, which is
>obviously wrong.  I'm not sure why slot 3 does not work, however,
>unless the code just thinks the PCI bridge *is* slot 3 (which it does
>appear to be that way).
>
>If no one is currently attempting to fix it, but someone would like to,
>here is all of the relevant info I can think of.  Thanks in advance for
>any help.

I had no time to fix that yet. email me in a couple of weeks, I'll have
finished moving and my boxes will be back up.

Note that it's not similar to the 9500, the 9500 has 2 host bridges while
you have only one with a PCI<->PCI bridge, the interrupt problem appear
to be specific to this configuration on an oldworld machine.

If you want to give it a look by yourself, the code that gets the
interrupt numbers is in arch/ppc/prom.c. Look at the bits that use the
"AAPL,interrupt" property and modify it slightly so that when it can't
find it, it looks for the parent.

Ben.


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

Re: Re: Status of PCI-PCI bridge on UMAX S900

[jingai]

> >Hello, I am just curious if anyone is working on getting the PCI-PCI
> >bridge code working for the UMAX S900...
>
> If you want to give it a look by yourself, the code that gets the
> interrupt numbers is in arch/ppc/prom.c. Look at the bits that use the
> "AAPL,interrupt" property and modify it slightly so that when it can't
> find it, it looks for the parent.

Ok, I've given it a more thorough looksee, and here is what I have done:

--- prom.c  Wed Dec 27 22:54:42 2000
+++ prom.c.old  Wed Dec 27 22:04:15 2000
@@ -1566,10 +1566,6 @@
    ip = (int *) get_property(np, "AAPL,interrupts", &l);
    if (ip == 0)
        ip = (int *) get_property(np, "interrupts", &l);
-   /* JSL: HACK FOR UMAX S900 PCI-PCI BRIDGE (DECchip 21052)
-    */
-   if (ip == 0 && np->parent != NULL)
-           ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
    if (ip != 0) {
        np->intrs = (struct interrupt_info *) mem_start;
        np->n_intrs = l / sizeof(int);

I have verified that the code I added is in fact called when it probes the
two
cards in slots 3 and 4; however, *ip == 1 for both cards.  It seems as
though
the IRQ info cannot be retrieved from AAPL,interrupts, or it is just
incorrect.

I did try *manually* setting the IRQs for these cards to 25 and 26, which
as I expected, did not work... (it appears to have the same effect as
when they are set to 1, considering that is also incorrect).

If it might help, the card in slot 4 is my second ethernet card (used for
my LAN -- internal is used for DSL), and it *does* work a little --
here is output from ping:

PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=7648.2 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=6656.9 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=5657.2 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=4654.8 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=255 time=3657.5 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=255 time=2656.7 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=255 time=1657.8 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=255 time=657.9 ms

--- 192.168.1.2 ping statistics ---
11 packets transmitted, 8 packets received, 27% packet loss
round-trip min/avg/max = 657.9/4155.8/7648.2 ms

As you might notice, 7648.2ms is pretty bad for a machine in the
next room :)  Not to mention the 27% packet loss..

Anyway, I think I am stepping out of my bounds here now... hopefully
this is enough information for someone to give me some more pointers
on where I should look..

/me really wishes he were a kernel guru right now :)

TIA,
Jonathan

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

Re: Status of PCI-PCI bridge on UMAX S900

[Chas Williams]

just a short followup to the message i sent to debian-powerpc, i applied the
following diff and was able to move my usb board to the other side of the
umax/s900 bridge w/o any ill effect:

--- prom.c.000  Thu Dec 28 08:43:12 2000
+++ prom.c      Thu Dec 28 09:06:16 2000
@@ -1563,8 +1563,8 @@
        }

        ip = (int *) get_property(np, "AAPL,interrupts", &l);
-       if (ip == 0)
-               ip = (int *) get_property(np, "interrupts", &l);
+       if (ip == 0 && np->parent != NULL)
+               ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
        if (ip != 0) {
                np->intrs = (struct interrupt_info *) mem_start;
                np->n_intrs = l / sizeof(int);

lspci, now shows:

01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE (prog-if 00 [VGA])
        Subsystem: Unknown device b530:0408
        Flags: bus master, stepping, medium devsel, latency 32, IRQ 25
        Memory at 84000000 (32-bit, prefetchable) [size=64M]
        I/O ports at 1000 [size=256]
        Memory at 80804000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 80820000 [disabled] [size=128K]
        Capabilities: <available only to root>

01:01.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
        Subsystem: OPTi Inc.: Unknown device c861
        Flags: bus master, medium devsel, latency 32, IRQ 25
        Memory at 80800000 (32-bit, non-prefetchable) [size=4K]

on a related, note, shouldnt the 'right' code be:

	ip = (int *) get_property(np, "interrupts", &l);
	if (ip > 0)
	{
		/* find and assign interrupt -- see above */
	}

pci boards should only get an interrupt if they have the interrupt property
(which seems to be the number of interrupts, not the interrupt number)

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

Re: Re: Status of PCI-PCI bridge on UMAX S900

[jingai]

> just a short followup to the message i sent to debian-powerpc, i applied
> the following diff and was able to move my usb board to the other side of
the
>
> umax/s900 bridge w/o any ill effect:
>
> --- prom.c.000  Thu Dec 28 08:43:12 2000
> +++ prom.c      Thu Dec 28 09:06:16 2000
> @@ -1563,8 +1563,8 @@
>         }
>
>         ip = (int *) get_property(np, "AAPL,interrupts", &l);
> -       if (ip == 0)
> -               ip = (int *) get_property(np, "interrupts", &l);
> +       if (ip == 0 && np->parent != NULL)
> +               ip = (int *) get_property(np->parent, "AAPL,interrupts",
> &l);
>         if (ip != 0) {
>                 np->intrs = (struct interrupt_info *) mem_start;
>                 np->n_intrs = l / sizeof(int);

Doh!  I didn't even think to check if the second get_property() call
was returning > 0.. this fixes it!  Thanks bunches for spotting that!

> on a related, note, shouldnt the 'right' code be:
>
>     ip = (int *) get_property(np, "interrupts", &l);
>     if (ip > 0)
>     {
>         /* find and assign interrupt -- see above */
>     }
>
> pci boards should only get an interrupt if they have the interrupt
> property (which seems to be the number of interrupts, not the interrupt
number)

Seems correct to me, but I'm no kernel guru, so I'll let someone else
answer
authoritatively.

-j


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

Re: Status of PCI-PCI bridge on UMAX S900

[Chas Williams]

In message <200012290016.SAA25126@lists.linuxppc.org>,jingai writes:
>Doh!  I didn't even think to check if the second get_property() call
>was returning > 0.. this fixes it!  Thanks bunches for spotting that!

it seems like someone was confused about the meaning of the 'interrupts'
property when they wrote prom.c.  its basically the number of interrupts
supported by this pci device.  interpret_dbdma_props() also has the
same confusion, so the following would be a more complete patch to
prom.c.  note that it checks to see if a pci node has an interrupt
property before assigning one, otherwise devices on the far side of
a pci bridge (that shares interrupts) would be assigned interrupts
when they dont need them.


--- prom.c.000	Thu Dec 28 08:43:12 2000
+++ prom.c	Fri Dec 29 10:05:54 2000
@@ -1562,9 +1562,12 @@
 		return mem_start;
 	}

+	if ((ip = (int *) get_property(np, "interrupts", &l)) == 0)
+		return mem_start;
+
 	ip = (int *) get_property(np, "AAPL,interrupts", &l);
-	if (ip == 0)
-		ip = (int *) get_property(np, "interrupts", &l);
+	if (ip == 0 && np->parent != NULL)
+		ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
 	if (ip != 0) {
 		np->intrs = (struct interrupt_info *) mem_start;
 		np->n_intrs = l / sizeof(int);
@@ -1615,9 +1618,12 @@
 	if (use_of_interrupt_tree)
 		return mem_start;

+	if ((ip = (int *) get_property(np, "interrupts", &l)) == 0)
+		return mem_start;
+
 	ip = (int *) get_property(np, "AAPL,interrupts", &l);
-	if (ip == 0)
-		ip = (int *) get_property(np, "interrupts", &l);
+	if (ip == 0 && np->parent != NULL)
+		ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
 	if (ip != 0) {
 		np->intrs = (struct interrupt_info *) mem_start;
 		np->n_intrs = l / sizeof(int);

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

Re: Status of PCI-PCI bridge on UMAX S900

[Tibor Pausz]

On Fre, 29. Dez 2000, Chas Williams <chas@cmf.nrl.navy.mil> wrote:

>In message <200012290016.SAA25126@lists.linuxppc.org>,jingai writes:
>>Doh!  I didn't even think to check if the second get_property() call
>>was returning > 0.. this fixes it!  Thanks bunches for spotting that!
>
>it seems like someone was confused about the meaning of the 'interrupts'
>property when they wrote prom.c.  its basically the number of interrupts
>supported by this pci device.  interpret_dbdma_props() also has the
>same confusion, so the following would be a more complete patch to
>prom.c.  note that it checks to see if a pci node has an interrupt
>property before assigning one, otherwise devices on the far side of
>a pci bridge (that shares interrupts) would be assigned interrupts
>when they dont need them.

Today I tried your patch. Well, I breaks the hole interrupt stuff.
Now, even Mesh has trouble with interrupts (kernel crash), the
console=ttyS0 doesn't work so no output from the booting ...

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

Re: Status of PCI-PCI bridge on UMAX S900

[Benjamin Herrenschmidt]

>>it seems like someone was confused about the meaning of the 'interrupts'
>>property when they wrote prom.c.  its basically the number of interrupts
>>supported by this pci device.  interpret_dbdma_props() also has the
>>same confusion, so the following would be a more complete patch to
>>prom.c.  note that it checks to see if a pci node has an interrupt
>>property before assigning one, otherwise devices on the far side of
>>a pci bridge (that shares interrupts) would be assigned interrupts
>>when they dont need them.
>
>Today I tried your patch. Well, I breaks the hole interrupt stuff.
>Now, even Mesh has trouble with interrupts (kernel crash), the
>console=ttyS0 doesn't work so no output from the booting ...

The "interrupts" property can have various meanings depending on the OF
version, I suggest you don't mess with it. Just check that if you find no
AAPL,interrupts, and that pmac_newworld == 0, then look for parent
AAPL,interrupts.

Ben.


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

Re: Status of PCI-PCI bridge on UMAX S900

[David Edelsohn]

>>>>> Benjamin Herrenschmidt writes:

Ben> The "interrupts" property can have various meanings depending on the OF
Ben> version, I suggest you don't mess with it. Just check that if you find no
Ben> AAPL,interrupts, and that pmac_newworld == 0, then look for parent
Ben> AAPL,interrupts.

	"interrupts" property is well-defined in the OF spec for each
device-tree node, but I do not think that prom.c currently has enough
parsing ability to handle the complexity or makes too many assumption.
And it does not need to fully parse that property, as Ben suggests.

David

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

Re: Status of PCI-PCI bridge on UMAX S900

[Benjamin Herrenschmidt]

>	"interrupts" property is well-defined in the OF spec for each
>device-tree node, but I do not think that prom.c currently has enough
>parsing ability to handle the complexity or makes too many assumption.
>And it does not need to fully parse that property, as Ben suggests.

I didn't say it wasn't well defined ;) I said it's usage by Apple is not.

prom.c has an interrupt tree parser that is used only on newworld macs
(they have a valid interrupt tree) and only when booting via Open
Firmware (booting via MacOS kills too much infos from the device tree to
be able to parse the interrupt tree any more).

I think it's also used on CHRP.

Ben.


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

Re: Status of PCI-PCI bridge on UMAX S900

[Benjamin Herrenschmidt]

>>	"interrupts" property is well-defined in the OF spec for each
>>device-tree node, but I do not think that prom.c currently has enough
>>parsing ability to handle the complexity or makes too many assumption.
>>And it does not need to fully parse that property, as Ben suggests.
>
>I didn't say it wasn't well defined ;) I said it's usage by Apple is not.

Hrm.. in fact, it looks like _I_ was not very clear, sorry


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

Re: Status of PCI-PCI bridge on UMAX S900

[Chas Williams]

In message <19341129125123.15815@mail.server.uni-frankfurt.de>,Tibor Pausz writ
es:
>Today I tried your patch. Well, I breaks the hole interrupt stuff.
>Now, even Mesh has trouble with interrupts (kernel crash), the
>console=ttyS0 doesn't work so no output from the booting ...

i was wrong about the checking for the interrupts property before
allocating an interrupt. the correct patch follows:

--- prom.c.000	Thu Dec 28 08:43:12 2000
+++ prom.c	Tue Jan  2 09:18:53 2001
@@ -1563,8 +1563,8 @@
 	}

 	ip = (int *) get_property(np, "AAPL,interrupts", &l);
-	if (ip == 0)
-		ip = (int *) get_property(np, "interrupts", &l);
+	if (ip == 0 && np->parent != NULL)
+		ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
 	if (ip != 0) {
 		np->intrs = (struct interrupt_info *) mem_start;
 		np->n_intrs = l / sizeof(int);
@@ -1616,8 +1616,8 @@
 		return mem_start;

 	ip = (int *) get_property(np, "AAPL,interrupts", &l);
-	if (ip == 0)
-		ip = (int *) get_property(np, "interrupts", &l);
+	if (ip == 0 && np->parent != NULL)
+		ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
 	if (ip != 0) {
 		np->intrs = (struct interrupt_info *) mem_start;
 		np->n_intrs = l / sizeof(int);

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

Re: Status of PCI-PCI bridge on UMAX S900

[Tibor Pausz]

On Don, 4. Jan 2001, Chas Williams <chas@cmf.nrl.navy.mil> wrote:

>i was wrong about the checking for the interrupts property before
>allocating an interrupt. the correct patch follows:

It doesn't no longer crash the machine, but my ISDN card doesn't
get a correct interrupt. Excatly the some stuff w/o the patch.

Well, I didn't know if the ISDN card works at all. So I swapped
the SCSI card and the ISDN card. The ISDN card crashes now the machine,
but without the ISDN card the SCSI cards fine behind the PCI bridge :-)

I don't have any problem (yet), hdparm cache trough put around 30MB/s.

(it's a SYM 53c875 card)

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

Re: Re: Status of PCI-PCI bridge on UMAX S900

[jingai]

> The "interrupts" property can have various meanings depending on the OF
> version, I suggest you don't mess with it. Just check that if you find no
> AAPL,interrupts, and that pmac_newworld == 0, then look for parent
> AAPL,interrupts.

So, then does the following patch seem valid?  If so, I'd appreciate it if
others with different macs (newworld and oldworld) could try it and let
me know if it breaks anything...

..and if not, how would one go about getting this into the official trees?


--- prom.c.old  Wed Jan  3 20:31:59 2001
+++ prom.c      Thu Jan  4 17:44:02 2001
@@ -1564,8 +1564,15 @@
        }

        ip = (int *) get_property(np, "AAPL,interrupts", &l);
-       if (ip == 0)
+       if (ip == 0) {
+           /* hack to force a look at the parent node for interrupts on
+            * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+            */
+           if (!pmac_newworld && np->parent != NULL)
+               ip = (int *) get_property(np->parent, "AAPL,interrupts",
&l);
+           else
                ip = (int *) get_property(np, "interrupts", &l);
+       }
        if (ip != 0) {
                np->intrs = (struct interrupt_info *) mem_start;
                np->n_intrs = l / sizeof(int);
@@ -1617,8 +1624,15 @@
                return mem_start;

        ip = (int *) get_property(np, "AAPL,interrupts", &l);
-       if (ip == 0)
+       if (ip == 0) {
+           /* hack to force a look at the parent node for interrupts on
+            * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+            */
+           if (!pmac_newworld && np->parent != NULL)
+               ip = (int *) get_property(np->parent, "AAPL,interrupts",
&l);
+           else
                ip = (int *) get_property(np, "interrupts", &l);
+       }
        if (ip != 0) {
                np->intrs = (struct interrupt_info *) mem_start;
                np->n_intrs = l / sizeof(int);
@@ -1774,8 +1788,15 @@
                return mem_start;

        ip = (int *) get_property(np, "AAPL,interrupts", &l);
-       if (ip == 0)
+       if (ip == 0) {
+           /* hack to force a look at the parent node for interrupts on
+            * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+            */
+           if (!pmac_newworld && np->parent != NULL)
+               ip = (int *) get_property(np->parent, "AAPL,interrupts",
&l);
+           else
                ip = (int *) get_property(np, "interrupts", &l);
+       }
        if (ip != 0) {
                np->intrs = (struct interrupt_info *) mem_start;
                np->n_intrs = l / sizeof(int);


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

Re: Status of PCI-PCI bridge on UMAX S900

[David Edelsohn]

	Do you only need to look at the immediate parent and not the
entire ancestor tree?

David

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