Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
> It may work, but the bridge secondary/subordinate numbers look wrong.
>
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
int i;
/*
* For CardBus bridges, we leave 4 bus numbers
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
max += 3;
for (i = 0; i < 4; i++)
child->resource[i] = >resource[PCI_BRIDGE_RESOURCES+i];
}
(Well, comment should say "we leave 3 bus numbers" ;-)
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Hi Jeff! > 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 Agreed. > > > 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) Why? Behind this bridge, there is bus #2, not bus #1. Bus #1 is behind the PCI-to-PCI bridge 00:11.0. > subordinate == 5, should be 2 (bus #2 follows us) The bus numbers assigned by the current kernel may look strange, but they are perfectly correct according to the definition above. The PCI specs don't enforce any specific ordering of bridges on the same bus, the only requirements are that that the secondary...subordinate ranges of the bridges don't overlap and that they are in the secondary+1...subordinate range of the parent bus (which is 01...FF for the root bus). > > 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) > > Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 [...] > > 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 [...] This gives us the following assignment: 00 root bus (01-FF allowed for its sub-busses) 01 secondary PCI 02-05 first cardbus 06-09 second cardbus which doesn't break the rules. > 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. Yes, it will break on any machine with multiple primary PCI busses, because the registers assigning bus number ranges to primary busses are chipset specific. In 2.5, I'd like to rewrite the resource + bus number assignment code to be able to re-layout the busses and resources even on i386 if it detects it's safe to do so (that is there is either only one primary bus or the host bridge is known). This will be needed for proper PCI hotplug and it will also help us to get rid of some more BIOS bugs (especially on some embedded systems). Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Hi Jeff! 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 Agreed. 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) Why? Behind this bridge, there is bus #2, not bus #1. Bus #1 is behind the PCI-to-PCI bridge 00:11.0. subordinate == 5, should be 2 (bus #2 follows us) The bus numbers assigned by the current kernel may look strange, but they are perfectly correct according to the definition above. The PCI specs don't enforce any specific ordering of bridges on the same bus, the only requirements are that that the secondary...subordinate ranges of the bridges don't overlap and that they are in the secondary+1...subordinate range of the parent bus (which is 01...FF for the root bus). 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 [...] 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 [...] This gives us the following assignment: 00 root bus (01-FF allowed for its sub-busses) 01 secondary PCI 02-05 first cardbus 06-09 second cardbus which doesn't break the rules. 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. Yes, it will break on any machine with multiple primary PCI busses, because the registers assigning bus number ranges to primary busses are chipset specific. In 2.5, I'd like to rewrite the resource + bus number assignment code to be able to re-layout the busses and resources even on i386 if it detects it's safe to do so (that is there is either only one primary bus or the host bridge is known). This will be needed for proper PCI hotplug and it will also help us to get rid of some more BIOS bugs (especially on some embedded systems). Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ "Anyone can build a fast CPU. The trick is to build a fast system." -- S. Cray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, Oct 25, 2000 at 05:59:39PM -0400, Jeff Garzik wrote:
It may work, but the bridge secondary/subordinate numbers look wrong.
No, these numbers look correct for me. Read comment in drivers/pci/pci.c:
if (!is_cardbus) {
/* Now we can scan all subordinate buses... */
max = pci_do_scan_bus(child);
} else {
int i;
/*
* For CardBus bridges, we leave 4 bus numbers
* as cards with a PCI-to-PCI bridge can be
* inserted later.
*/
max += 3;
for (i = 0; i 4; i++)
child-resource[i] = dev-resource[PCI_BRIDGE_RESOURCES+i];
}
(Well, comment should say "we leave 3 bus numbers" ;-)
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
