There are other bogosities in drivers/char/agp/generic.c.  I can't
believe Dave ever tested that code with an AGP 3.0 device.  If you pass
in a mode that has the AGP 3.0 bit set, agp_v3_parse_one() will first
clear that bit (and print a message), and then complain because you
haven't got that bit set in the mode, with a message that the caller is
broken.  Furthermore, if the mode passed in has both the 4x and 8x bits
set, the new code will give you 4x where the old code would give you 8x
(which is what the caller wanted).

The patch below fixes this.  It will work in the 99.99% of cases where
we have one AGP bridge and one AGP video card.  We should eventually
cope with multiple AGP bridges, but doing the matching of bridges to
video cards is a hard problem because the video card is not necessarily
a child or sibling of the PCI device that we use for controlling the AGP
bridge.  I think we need to see an actual example of a system with
multiple AGP bridges first.

Oh, and by the way, I have 3D working relatively well on my G5 with a
64-bit kernel (and 32-bit X server and clients), which is why I care
about AGP 3.0 support.  :)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>