Re: AGP bogosities

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> I still don't quite understand this.  If the host bridge is not a
> PCI device, what PCI device contains the AGP capability that controls
> the host bridge?  I assume you're saying that you are required to
> have TWO PCI devices that have the AGP capability, one for the AGP
> device and one for the bridge.
> 
> HP boxes certainly don't have that (zx6000 sample below).  I guess
> it wouldn't be the first time we deviated from a spec ;-)

We are basically hitting a "hole" in the PCI spec itself :) It doesn't
really defines how a host bridge can expose itself as a device. That
means that in most cases, the host bridge either isn't visible at all,
or is as a random device at the first level (which makes it a sibling of
other devices, quite broken ....). Also, there is no standard "devfn"
for it, so it can be anywhere and there is no "simple" way of knowing
which devie is actually the host in a generic way. Most of the time,
looking for a devie with the class "host bridge" will work, but it's not
guaranteed. Some hosts also expose the AGP stuff differently.

In some cases, like Apple U3 HT host, it also has a set of registers
that mimmic a PCI config space, but aren't implemented in the PCI config
space proper, and thus, unless you add special case to your pci_ops, you
won't see it on the bus. (Apple's AGP host appears as a device on it's
own bus though).

So while AGP requires a set of PCI config space registers with the AGP
capabilities for the host, it's very possible that you have those in a
space that don't appear on the PCI (just as MMIO registers on your
bridge somewhere), or whatever other fancy setup. In fact, that part of
the spec hits the above hole, so I wouldn't be surprised if vendors
decided to ignore it and do fancy things.

Ben.