Messages in this thread | | | Date | Thu, 8 Aug 2002 17:21:00 +0400 | From | Ivan Kokshaysky <> | Subject | Re: PCI<->PCI bridges, transparent resource fix |
| |
On Thu, Aug 08, 2002 at 10:20:15AM +0200, Benjamin Herrenschmidt wrote: > Unfortunately that wouldn't work as I actually have 3 host bridges > on these models, and the windows can be "mixed". One host can have > 0x80000000 to 0x9ffffffff (and one region at 0xfx000000), The next > one can have 0xa0000000 to 0xaffffffff and another region at > 0xfx000000, etc...
Please elaborate. I always thought that 3 host bridges (controllers, hoses and so on) mean 3 physically separated PCI buses. In this case the approach with only one root bus structure is plain wrong - resource allocation won't work correctly. You should have 3 root buses, and apply suggested workaround to all 3. Or am I missing something?
> >There are only 3, as Grant pointed out. :-) > > Well, I as pointed out, I may actually need all 4 regions of the host ;)
I still hope you won't :-)
> Anyway, since we agree on copying down the parent regions, and the pci_bus > stucture holds 4 resource slots, then let's copy them all down.
I think 4th slot makes no sense in terms of the PCI bus and should be killed. I guess that initially it was intended for cardbus drivers (for 2nd IO window), but it seems that they don't use pci_bus->resource pointers at all.
> I'll write some code about that when I'm back from vacation and we'll > see what's up. I may end up adding a quirk call inside the > pci_read_bridge_bases > functions so that it's behaviour can be easily overriden if we ever meet > a non-strandard enough bridge to be transparent without having ProgIf code 1
This can be easily done with generic quirks:
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_XXX, PCI_DEVICE_ID_BAD_BRIDGE, quirk_transparent_bridge } ... static void __init quirk_transparent_bridge(struct pci_dev *dev) { dev->class |= 1; }
Ivan. - 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/
| |