Re: [patch 2/2] x86_64: Collect host bridge resources

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

On Tue, May 24, 2005 at 10:37:25AM -0700, Rajesh Shah wrote:
> For the transparent p2p bridge problem you mentioned, wouldn't you
> be dealing with p2p bridges, and therefore expect the pci_bus
> resource pointers to point to the corresponding pci_dev resources?

The problem is that for subtractive decode bridges we assume
full "transparency" and completely ignore standard p2p bridge
resources (i.e. windows) just using first 3 parent bus pointers
whatever they are.
This model does work in most cases, but there are potential problems
with peer-to-peer DMA behind such bridges, poor performance for MMIO
ranges outside bridge windows, prefetchable vs. non-prefetchable issues
and so on.

If we had 6 or more resource pointers in struct pci_bus, then the
appended patch would fix that.

> Or are you proposing to decouple pci_bus resource pointers from 
> pci_dev completely?

Actually no. Low-level bridge drivers (p2p, cardbus or particular
host bridge) certainly know about resource layout of the respective
device. But generic resource management code doesn't make any
assumptions about that and looks only at resource types.

> From quick code inspection, that seems to be
> not too much trouble to increase from 4 then.

No trouble at all, I guess.

Ivan.

--- linux/drivers/pci/probe.c.orig	Sat May  7 09:20:31 2005
+++ linux/drivers/pci/probe.c	Wed May 25 18:31:34 2005
@@ -239,9 +239,8 @@ void __devinit pci_read_bridge_bases(str
 
 	if (dev->transparent) {
 		printk(KERN_INFO "PCI: Transparent bridge - %s\n", pci_name(dev));
-		for(i = 0; i < PCI_BUS_NUM_RESOURCES; i++)
-			child->resource[i] = child->parent->resource[i];
-		return;
+		for(i = 3; i < PCI_BUS_NUM_RESOURCES; i++)
+			child->resource[i] = child->parent->resource[i - 3];
 	}
 
 	for(i=0; i<3; i++)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/