Bug 13190 - Radeon driver doesn't detect AGP v3 with X700 AGP
Summary: Radeon driver doesn't detect AGP v3 with X700 AGP
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-11 19:15 UTC by Lukasz Krotowski
Modified: 2007-11-13 14:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
AGP v3 forced detection patch. (375 bytes, patch)
2007-11-11 19:15 UTC, Lukasz Krotowski
no flags Details | Splinter Review
Syslog parts with agpgart messages. (779 bytes, text/plain)
2007-11-11 19:16 UTC, Lukasz Krotowski
no flags Details
lspci -vv output. (15.35 KB, text/plain)
2007-11-11 19:17 UTC, Lukasz Krotowski
no flags Details
Xorg log with patched driver. (45.35 KB, text/plain)
2007-11-11 19:17 UTC, Lukasz Krotowski
no flags Details
Xorg log without patched driver, AGPMode set to 4. (45.26 KB, text/plain)
2007-11-11 19:24 UTC, Lukasz Krotowski
no flags Details

Description Lukasz Krotowski 2007-11-11 19:15:02 UTC
xf86-video-ati does not detect X700 AGP card as AGP v3 capable. But kernel agpagart does (lspci also). Which leads to inconsistency (driver sets AGP 4x, agpgart 8x). When driver is forced (simple patch attached) to recognize card as AGP v3 everything works ok.
Comment 1 Lukasz Krotowski 2007-11-11 19:15:47 UTC
Created attachment 12466 [details] [review]
AGP v3 forced detection patch.
Comment 2 Lukasz Krotowski 2007-11-11 19:16:24 UTC
Created attachment 12467 [details]
Syslog parts with agpgart messages.
Comment 3 Lukasz Krotowski 2007-11-11 19:17:01 UTC
Created attachment 12468 [details]
lspci -vv output.
Comment 4 Lukasz Krotowski 2007-11-11 19:17:56 UTC
Created attachment 12469 [details]
Xorg log with patched driver.
Comment 5 Lukasz Krotowski 2007-11-11 19:24:30 UTC
Created attachment 12470 [details]
Xorg log without patched driver, AGPMode set to 4.

When AGPMode is 8 driver complains that 8 is invalid and sets AGP 1x.
Comment 6 Roland Scheidegger 2007-11-12 07:28:56 UTC
(In reply to comment #5)
> Created an attachment (id=12470) [details]
> Xorg log without patched driver, AGPMode set to 4.
> 
> When AGPMode is 8 driver complains that 8 is invalid and sets AGP 1x.

Seems like the chip is lying about being in agp 3.0 or agp 2.0 mode - those cards have the rialto bridge chip. The agpgart driver ignores this probably and just uses whatever the bridge says the mode is (which must match).
Maybe we should just do the same.
So changing agp_status to this might work:
    /* ignore agp 3.0 mode bit from the chip as it's buggy on some cards with pcie-agp rialto bridge chip - use the one from bridge which must match */
    CARD32 agp_status = ((INREG(RADEON_AGP_STATUS) | RADEON_AGPv3_MODE) & mode;
Does this work for you? I guess this change should be safe.
Comment 7 Lukasz Krotowski 2007-11-12 08:53:53 UTC
(In reply to comment #6)
> Seems like the chip is lying about being in agp 3.0 or agp 2.0 mode - those
> cards have the rialto bridge chip. The agpgart driver ignores this probably and
> just uses whatever the bridge says the mode is (which must match).
> Maybe we should just do the same.
> So changing agp_status to this might work:
>     /* ignore agp 3.0 mode bit from the chip as it's buggy on some cards with
> pcie-agp rialto bridge chip - use the one from bridge which must match */
>     CARD32 agp_status = ((INREG(RADEON_AGP_STATUS) | RADEON_AGPv3_MODE) & mode;
> Does this work for you? I guess this change should be safe.

Yes, it works like a charm.
Comment 8 James Spencer 2007-11-13 13:19:12 UTC
I just wanted to say that I have the same card, with the same issue. When the next driver hits Debian Experimental I'll keep this page bookmarked and report back any strangeness.
Comment 9 Roland Scheidegger 2007-11-13 14:45:26 UTC
Ok pushed. Blame me if it causes other setups to fail :-).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.