On Tue, Aug 06, 2002 at 10:31:34PM +0200, Benjamin Herrenschmidt wrote:> Well, it's definitely not that specific since I know several host> bridges that have several programmable windows to PCI, and those> aren't PPC specifc. In the case of pmacs, the UniNorth bridge> forwards up to 7 regions of 256Mb (0x80000000..0x8fffffff,> 0x90000000..0x9fffffff, etc... up to 0xe0000000..0xefffffff),> each of them beeing selected by a bit setup by the firmware.> It then have additional 16 regions of type 0xfx000000 than can> also be individually selected, some of them beeing reserved for> IO and config space, but one of them beeing typically an additional> memory window to the PCI bus.

Ok. Assume that additional window is 0xf2000000-0xf2ffffff.I'd try the following:- set the _single_ memory resource of the root bus to 0x80000000-0xf2ffffff;- create dummy memory type resource 0xf0000000-0xf1ffffff and "claim" it on the root bus. This will prevent all further allocations in the gap between two MMIO windows.I think it should seriously simplify the things.> Ok, here we need Linus answert. We did have a patch in the PPC tree> that was consideing closed resources as really closed instead of> transparent, and we were told by Linus that there were non standard> bridges and various issues in the x86 world with that, and that those> would remain transparent. I don't have pointers at hand, but I think> this was dicusssed on lkml several monthes ago.

I recall that. I do agree with Linus, but only about bridges withclass code 0x60401 (subtractive decoders). The details of operating insubtractive decoding mode are beyond the scope of the P2P bridge specs,and probably we don't want to know these details either. "Assumingtransparent" is a sufficient workaround in this case.

Some additional notes. The P2P bridge specification says:"The primary use of a subtractive decoding bridge is to connect a laptop system to a docking station and support legacy ISA devices in the docking station."

Indeed, that "transparency" code had been added to fix P2P bridge problemson some Dell docking station (reported by Jamal) back in the 2.4.0-testtimes. Unfortunately, lspci output of that machine hasn't been posted(or I just missed that). However, I'm sure that the problematic bridgedid have ProgIf code 1, otherwise that type of machines would haveproblems running Windows, as MS says: "A bridge indicates that it performs subtractive decode if its Programming Interface bit in the PCI Configuration Register is set to 01h. Not all PCI-to-PCI bridges support subtractive decode. Windows will not switch a bridge from positive decode to subtractive decode (or vice versa) because there is no standard method defined for this action."

> I'd set all 4 then, thus the bridge would really be seen as forwarding> all the regions of the host bridge, whatever they are.

There are only 3, as Grant pointed out. :-)

> That makes sense. This would also allow to spot that there is no device> below a PCI<->PCI bridge when doing that assignement of unassigned> resources, and thus to spot that the firmware may have indeed been> right to close them and not to bother.