Debian Bug report logs - #508999
xserver-xorg-video-radeon: wrong frequencies on DVI output

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: submitt@bugs.debian.org

Subject: xserver-xorg-video-radeon: wrong frequencies on DVI output

Date: Wed, 17 Dec 2008 09:44:51 +0100

[Message part 1 (text/plain, inline)]

Package: xserver-xorg-video-radeon
Version: 1:6.9.0-1+lenny4
Severity: important

With a
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS482 [Radeon Xpress 200] [1002:5974]
01:05.1 Display controller [0380]: ATI Technologies Inc Radeon Xpress Series (RS482) [1002:5874]
which worked under etch, I only get a black screen and a warning
of wrong frequences (HFreq 90.1KHz, VFreq 90.2Hz) from the display.
(I've tried to switch to the xserver-xorg-video-vesa, but while that
mostly worked, it seems to be a bit unstable and sometimes hangs the
computer on VT switches or X server restarts).

Looking at #481361 I tried radeondump to generate some dumps. And
suprisingly,
doing the dump causes the output to change so the TFT can display it.
When I change to virtual console and back, I get again a blank screen
with
the frequency warning.

The attched .dump files were created running
sleep 5 ; /path/to/radeontool regmatch '*' > first.dump ; sleep 3 ; /path/to/radeontool regmatch '*' > second.dump
on the console, then switching back to X. After the 5 seconds are
over, the xdm greeter becomes visible, and usual working becomes possible,
until switching to the console and back to X.

Architecture is i386,
kernel is 2.6.26-1-amd64
xorg.conf and log file attached.

Hochachtungsvoll,
	Bernhard R. Link

[first.dump (text/plain, attachment)]

[second.dump (text/plain, attachment)]

[Xorg.0.log (text/plain, attachment)]

[xorg.conf (text/plain, attachment)]

Message #10 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: 508999@bugs.debian.org

Subject: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Fri, 19 Dec 2008 19:56:33 +0100

Checking which of the registers to read with radeontool causes the graphic
card to start using proper frequencies, those are luckily those were
radeontool writes something before reading namely:

PIXCLKS_CNTL
VCLK_ECP_CNTL
PPLL_DIV_0
PPLL_CNTL
CLK_PIN_CNTL
SCLK_CNTL
PWRMAN_MISC
SS_INT_CNTL

I did not test all, but CLK_PIN_CNTL is the only one of A* B* C* and D*
that helps and all the other of that list help, too.

what redeontool does is setting
*(unsigned int * volatile)(radeon_cntl_mem + RADEON_CLOCK_CNTL_INDEX)
to a value of 0x2d, 0x08, 0x04, 0x02, 0x01, 0x0d, 0x16 or 0x33 and
then reading
*(unsigned int * volatile)(radeon_cntl_mem + RADEON_CLOCK_CNTL_DATA)

Hochachtungsvoll,
	Bernhard R. Link

Message #15 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: 508999@bugs.debian.org

Subject: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Sat, 20 Dec 2008 19:48:23 +0100

Looking at the radeon_drv sources, it looks like those are only
accessing 8 bit at RADEON_CLOCK_CNTL_INDEX and not the whole int that
radeontool is writing, changing that in the driver via

--- xserver-xorg-video-ati-6.9.0/src/radeon_driver.c	2008-12-20 19:06:32.000000000 +0100
+++ xserver-xorg-video-ati-6.9.0/src/radeon_driver.c	2008-12-20 18:29:24.000000000 +0100
@@ -544,7 +544,7 @@
     unsigned char *RADEONMMIO = info->MMIO;
     uint32_t       data;
 
-    OUTREG8(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
+    OUTREG(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
     RADEONPllErrataAfterIndex(info);
     data = INREG(RADEON_CLOCK_CNTL_DATA);
     RADEONPllErrataAfterData(info);
@@ -558,7 +558,7 @@
     RADEONInfoPtr  info       = RADEONPTR(pScrn);
     unsigned char *RADEONMMIO = info->MMIO;
 
-    OUTREG8(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
+    OUTREG(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
 				      RADEON_PLL_WR_EN));
     RADEONPllErrataAfterIndex(info);
     OUTREG(RADEON_CLOCK_CNTL_DATA, data);

fixes my problem (i.e. I get a working display, and it still works after
switching to virtual console and back and changing resolutions and all those
things).

I fear that might be the case because it is overwriting some other data
in there that causes this, but I guess to know this someone with
knowledge about this registers is needed...

Hochachtungsvoll,
	Bernhard R. Link

Message #20 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Alex Deucher" <alexdeucher@gmail.com>

To: "Bernhard R. Link" <brlink@debian.org>, 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Mon, 22 Dec 2008 04:18:48 -0500

[Message part 1 (text/plain, inline)]

On Sat, Dec 20, 2008 at 1:48 PM, Bernhard R. Link <brlink@debian.org> wrote:
> Looking at the radeon_drv sources, it looks like those are only
> accessing 8 bit at RADEON_CLOCK_CNTL_INDEX and not the whole int that
> radeontool is writing, changing that in the driver via
>
> --- xserver-xorg-video-ati-6.9.0/src/radeon_driver.c    2008-12-20 19:06:32.000000000 +0100
> +++ xserver-xorg-video-ati-6.9.0/src/radeon_driver.c    2008-12-20 18:29:24.000000000 +0100
> @@ -544,7 +544,7 @@
>     unsigned char *RADEONMMIO = info->MMIO;
>     uint32_t       data;
>
> -    OUTREG8(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
> +    OUTREG(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
>     RADEONPllErrataAfterIndex(info);
>     data = INREG(RADEON_CLOCK_CNTL_DATA);
>     RADEONPllErrataAfterData(info);
> @@ -558,7 +558,7 @@
>     RADEONInfoPtr  info       = RADEONPTR(pScrn);
>     unsigned char *RADEONMMIO = info->MMIO;
>
> -    OUTREG8(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
> +    OUTREG(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
>                                      RADEON_PLL_WR_EN));
>     RADEONPllErrataAfterIndex(info);
>     OUTREG(RADEON_CLOCK_CNTL_DATA, data);
>
> fixes my problem (i.e. I get a working display, and it still works after
> switching to virtual console and back and changing resolutions and all those
> things).
>
> I fear that might be the case because it is overwriting some other data
> in there that causes this, but I guess to know this someone with
> knowledge about this registers is needed...

We only use the lower 8 bits because bits 9:8 select the pll dividers
to use; changing it breaks some chips.  Some rv410 chips have a
similar issue.  Does this patch fix it for you?

Alex

[debian508999.diff (text/plain, attachment)]

Message #25 received at 508999@bugs.debian.org (full text, mbox, reply):

From: Michel Dänzer <daenzer@debian.org>

To: "Bernhard R. Link" <brlink@debian.org>, 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Mon, 22 Dec 2008 10:41:12 +0100

On Sat, 2008-12-20 at 19:48 +0100, Bernhard R. Link wrote:
> Looking at the radeon_drv sources, it looks like those are only
> accessing 8 bit at RADEON_CLOCK_CNTL_INDEX and not the whole int that
> radeontool is writing, changing that in the driver via
> 
> --- xserver-xorg-video-ati-6.9.0/src/radeon_driver.c	2008-12-20 19:06:32.000000000 +0100
> +++ xserver-xorg-video-ati-6.9.0/src/radeon_driver.c	2008-12-20 18:29:24.000000000 +0100
> @@ -544,7 +544,7 @@
>      unsigned char *RADEONMMIO = info->MMIO;
>      uint32_t       data;
>  
> -    OUTREG8(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
> +    OUTREG(RADEON_CLOCK_CNTL_INDEX, addr & 0x3f);
>      RADEONPllErrataAfterIndex(info);
>      data = INREG(RADEON_CLOCK_CNTL_DATA);
>      RADEONPllErrataAfterData(info);
> @@ -558,7 +558,7 @@
>      RADEONInfoPtr  info       = RADEONPTR(pScrn);
>      unsigned char *RADEONMMIO = info->MMIO;
>  
> -    OUTREG8(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
> +    OUTREG(RADEON_CLOCK_CNTL_INDEX, (((addr) & 0x3f) |
>  				      RADEON_PLL_WR_EN));
>      RADEONPllErrataAfterIndex(info);
>      OUTREG(RADEON_CLOCK_CNTL_DATA, data);
> 
> fixes my problem (i.e. I get a working display, and it still works after
> switching to virtual console and back and changing resolutions and all those
> things).
> 
> I fear that might be the case because it is overwriting some other data
> in there that causes this, but I guess to know this someone with
> knowledge about this registers is needed...

Register specs are available from
http://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu or http://www.x.org/docs/AMD/ .

As can be seen there, CLOCK_CNTL_INDEX is indeed a 32 bit register with
more than 8 functional bits, so this looks like a valid fix.

In fact, I can't seem to find any non-32-bit MMIO registers we would
(need to) use, so I'm not sure the IN/OUTREG8 and IN/OUTREG16 macros
have any reason to live.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Message #30 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: Alex Deucher <alexdeucher@gmail.com>

Cc: 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Mon, 22 Dec 2008 11:17:05 +0100

[Message part 1 (text/plain, inline)]

* Alex Deucher <alexdeucher@gmail.com> [081222 10:18]:
> We only use the lower 8 bits because bits 9:8 select the pll dividers
> to use; changing it breaks some chips.  Some rv410 chips have a
> similar issue.  Does this patch fix it for you?

The patch does not apply cleanly on the lenny version, it looks like the
first two lines of this are swapped:

>  		RADEONRestoreFP2Registers(pScrn, info->ModeReg);
>  		RADEONRestoreDVOChip(pScrn, output);
> +		if ((radeon_crtc->crtc_id == 0) && info->IsIGP)
> +		    RADEONSelDiv0(pScrn);

Even when I switch those lines so that it applies, it does not work.

> @@ -1419,6 +1423,8 @@ legacy_output_mode_set(xf86OutputPtr output, DisplayModePtr mode,
>      case MT_LCD:
>  	ErrorF("restore LVDS\n");
>  	RADEONRestoreLVDSRegisters(pScrn, info->ModeReg);
> +	if ((radeon_crtc->crtc_id == 0) && (info->ChipFamily == CHIP_FAMILY_RV410))
> +	    RADEONSelDiv0(pScrn);
>  	break;

The cards I have here are 1002:5974 and grep 5974 src/radeon_chipinfo_gen.h
says:
 { 0x5974, CHIP_FAMILY_RS480, 1, 1, 0, 0, 1 },

Thus I added CHIP_FAMILY_RS480 there and then it seems to work. Modified patch
attached.

BTW: I was quite confused by the "ErrorF" there and first thought that
was an error path normaly not used and thus a bit perplexed why changing
that code even helps, but looking at the Xorg.log, it seems to be
actually called....

Hochachtungsvoll,
	Bernhard R. Link

[ati.diff (text/x-diff, attachment)]

Message #35 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Alex Deucher" <alexdeucher@gmail.com>

To: "Bernhard R. Link" <brlink@debian.org>

Cc: 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Mon, 22 Dec 2008 11:03:14 -0500

On Mon, Dec 22, 2008 at 5:17 AM, Bernhard R. Link <brlink@debian.org> wrote:
> * Alex Deucher <alexdeucher@gmail.com> [081222 10:18]:
>> We only use the lower 8 bits because bits 9:8 select the pll dividers
>> to use; changing it breaks some chips.  Some rv410 chips have a
>> similar issue.  Does this patch fix it for you?
>
> The patch does not apply cleanly on the lenny version, it looks like the
> first two lines of this are swapped:
>
>>               RADEONRestoreFP2Registers(pScrn, info->ModeReg);
>>               RADEONRestoreDVOChip(pScrn, output);
>> +             if ((radeon_crtc->crtc_id == 0) && info->IsIGP)
>> +                 RADEONSelDiv0(pScrn);
>
> Even when I switch those lines so that it applies, it does not work.
>
>> @@ -1419,6 +1423,8 @@ legacy_output_mode_set(xf86OutputPtr output, DisplayModePtr mode,
>>      case MT_LCD:
>>       ErrorF("restore LVDS\n");
>>       RADEONRestoreLVDSRegisters(pScrn, info->ModeReg);
>> +     if ((radeon_crtc->crtc_id == 0) && (info->ChipFamily == CHIP_FAMILY_RV410))
>> +         RADEONSelDiv0(pScrn);
>>       break;
>
> The cards I have here are 1002:5974 and grep 5974 src/radeon_chipinfo_gen.h
> says:
>  { 0x5974, CHIP_FAMILY_RS480, 1, 1, 0, 0, 1 },
>
> Thus I added CHIP_FAMILY_RS480 there and then it seems to work. Modified patch
> attached.
>
> BTW: I was quite confused by the "ErrorF" there and first thought that
> was an error path normaly not used and thus a bit perplexed why changing
> that code even helps, but looking at the Xorg.log, it seems to be
> actually called....

Can you try ati from git master with my patch?  The version you are
using doesn't properly deal with mobile vs desktop usage of rs4xx
chips (the version is git does).  The LVDS path shouldn't be getting
called in your case and I want to make sure the proper paths work
correctly.

Thanks,

Alex

Message #40 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: Alex Deucher <alexdeucher@gmail.com>

Cc: 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Mon, 22 Dec 2008 18:54:09 +0100

* Alex Deucher <alexdeucher@gmail.com> [081222 17:02]:
> Can you try ati from git master with my patch?  The version you are
> using doesn't properly deal with mobile vs desktop usage of rs4xx
> chips (the version is git does).  The LVDS path shouldn't be getting
> called in your case and I want to make sure the proper paths work
> correctly.

I tried c0c33dab44e6966b1702d4e8cfba3537fc6e2d5c
from git://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
and that seems to work both with and without patch.
(xrandr also names this device DVI-0 instead of the LVDS
of the lenny version).

While testing this when terminating the server with the patched new
radeon_drv.so, I got some error of suddenly no signal at all
and the computer very slow (especially disk accesses it seems).
It only happened with the patched git version yet, but it happens
so seldom that it might be coincidence and I just was not yet able to
reproduce with other versions...

Hochachtungsvoll,
	Bernhard R. Link

Message #45 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: Alex Deucher <alexdeucher@gmail.com>

Cc: 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Tue, 23 Dec 2008 16:15:49 +0100

* Bernhard R. Link <brlink@debian.org> [081222 19:01]:
> I tried c0c33dab44e6966b1702d4e8cfba3537fc6e2d5c
> from git://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
> and that seems to work both with and without patch.
> (xrandr also names this device DVI-0 instead of the LVDS
> of the lenny version).

I've tried to track this down with bisect in the hope there might be a
simple fix to cherrypick, but it doesn't look easy:

cb0deba5412a575d36f2f99377120b123506c946 has wrong frequencies
4dbdeea7c9316575fba26b41fd347452e42cdcf2 is the first to work
(strange as this has "cleanup" as description, but that's
how it is)

the 7 commits in between, the X server refuses to start here.
it claims DVI-0 is disconnected and thus no usable screens...

Hochachtungsvoll,
	Bernhard R. Link

Message #50 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Alex Deucher" <alexdeucher@gmail.com>

To: "Bernhard R. Link" <brlink@debian.org>

Cc: 508999@bugs.debian.org

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Tue, 23 Dec 2008 12:39:25 -0500

It's probably some variation of these commits that fixed things.  It's
probably easier to just use 6.9.0.99 or the soon to be released 6.9.1

eb65ddf70d182b6457e1ef5ebb820456039e8f6d
8b8990917809b9a35c6e9c1b9e3b12ff81c6dbb3
33f88f7fc90d9d93fdcbba9ad59dd70a6596bc3f
df0d1ef53100f0a19c5b5fdc349f5186c8d9bd87

Alex

On Tue, Dec 23, 2008 at 10:15 AM, Bernhard R. Link <brlink@debian.org> wrote:
> * Bernhard R. Link <brlink@debian.org> [081222 19:01]:
>> I tried c0c33dab44e6966b1702d4e8cfba3537fc6e2d5c
>> from git://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
>> and that seems to work both with and without patch.
>> (xrandr also names this device DVI-0 instead of the LVDS
>> of the lenny version).
>
> I've tried to track this down with bisect in the hope there might be a
> simple fix to cherrypick, but it doesn't look easy:
>
> cb0deba5412a575d36f2f99377120b123506c946 has wrong frequencies
> 4dbdeea7c9316575fba26b41fd347452e42cdcf2 is the first to work
> (strange as this has "cleanup" as description, but that's
> how it is)
>
> the 7 commits in between, the X server refuses to start here.
> it claims DVI-0 is disconnected and thus no usable screens...
>
> Hochachtungsvoll,
>        Bernhard R. Link
>

Message #55 received at 508999-done@bugs.debian.org (full text, mbox, reply):

From: Brice Goglin <Brice.Goglin@ens-lyon.org>

To: 508999-done@bugs.debian.org, "Bernhard R. Link" <brlink@debian.org>

Subject: Re: Bug#508999: more on 508999 (lenny with wrong frequencies on Radeon Xpress 200)

Date: Thu, 25 Dec 2008 17:47:51 +0100

Version: 1:6.9.0.91-1


Alex Deucher wrote:
> It's probably some variation of these commits that fixed things.  It's
> probably easier to just use 6.9.0.99 or the soon to be released 6.9.1
>   

Bernhard,
FYI, 6.9.0.91 is in experimental (built for Xserver 1.5), so I marking
the bug as fixed there.
Brice

Message #60 received at 508999@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: 508999@bugs.debian.org

Subject: patch for #508999 (wrong frequencies on Radeon Xpress 200) for lenny

Date: Mon, 5 Jan 2009 10:40:44 +0100

[Message part 1 (text/plain, inline)]

As the experimental version needs so many changes, how about the
attached patch to fix the issue for lenny?

It modifies nothing but adds another RADEON_CLOCK_CNTL_INDEX to 0
setting, like it is already there for CHIP_FAMILY_RV410, just more
limited (not within RADEONRestoreLVDSRegisters but only after one
specific call of it and with more guards) and changes nothing else.

Thanks in advance,
	Bernhard R. Link

[radeon-diff (text/plain, attachment)]

Send a report that this bug log contains spam.