lkml.org 
[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
It may work, but the bridge secondary/subordinate numbers look wrong.

I am pondering if the bus numbering/bridging stuff shouldn't be given a
good looking-over. I have the wonderful _PCI System Architecture, 4th
Ed._ in my hands, and it describes PCI-PCI bridge init in great detail,
including several multi-bus, multi-bridge examples. (Martin, run don't
walk to amazon to get this book.) Anyway, this book seems to imply that
we are getting stuff really wrong somewhere.

First, some definitions:
downstream - away from the host processor
primary - number of the PCI bus closer to the host processor
secondary - number of the PCI bus on the downstream side of the PCI
bridge
subordinate - number of the highest-numbered bus on the downstream side
of the PCI bridge


> 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01)
> Bus: primary=00, secondary=02, subordinate=05, sec-latency=0

First bridge on bus 0.
primary == 0 - ok
secondary == 2, should be 1 (bus #1 is behind this bridge)
subordinate == 5, should be 2 (bus #2 follows us)


> 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)
> Bus: primary=00, secondary=06, subordinate=09, sec-latency=0

Second bridge on bus 0.
primary == 0 - ok
secondary == 6, should be 2 (bus #2 behind this bridge)
subordinate == 9, should be 3 (bus #3 follows us)

> 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80)
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0

Third bridge on bus 0.
primary == 0 - ok
secondary == 1, should be 3 (bus #3 behind this bridge)
subordinate == 1, should be 3 (no bus follows, so
subordinate==secondary)

Now... this final bridge, the PCI (not CardBus) bridge, actually looks
ok... if you imagine that the third bridge is configured before the
CardBus bridges for some reason. Bus number 1 appears to be laid out
correctly.

However, the two CardBus bridges have totally wrong values for the
secondary and subordinate bridge numbers, whatever the cause.

Questions:

Martin, any idea why the bridges are numbered like this?

Second, will anything break if bus numbers change on x86? There exists
pcibios_assign_all_busses() on all platforms... but only Alpha defines
it to 1. All others define it to zero.

include/asm-alpha/pci.h:
/* Override the logic in pci_scan_bus for skipping
already-configured bus numbers. */
#define pcibios_assign_all_busses() 1

And Jamal, can you privately e-mail me your 'dmesg' output (with
debugging enabled in pci-i386.h), from -before- applying patches.

Regards,

Jeff



--
Jeff Garzik | Raft naked...
Building 1024 | It adds color to your cheeks.
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.070 / U:4.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site