Re: PCI<->PCI bridges, transparent resource fix

From: Ivan Kokshaysky (ink@jurassic.park.msu.ru)
Date: Thu Aug 08 2002 - 08:21:00 EST


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/



This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:16 EST