Bug 32556

Summary: [RADEON:KMS:PLL] screen flickers all the time with desktop image appearing only briefly
Product: DRI Reporter: Gildas Le Nadan <3ntr0p13>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: critical    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg
none
Xorg.log
none
UMS register dump as per #28331
none
KMS register dump as per #28331
none
patch proposed by Alex Deucher
none
after proposed patch #2 was applied
none
add new pll flag
none
patch+RADEON_PLL_PREFER_CLOSEST_HIGHER
none
patch + RADEON_PLL_NO_ODD_POST_DIV
none
vbios.rom
none
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER
none
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV
none
adjust up the clock slightly on rs6xx TDMS
none
ppll stability fixes for rs690
none
possible fix none

Description Gildas Le Nadan 2010-12-21 09:33:04 UTC
Created attachment 41344 [details] [review]
dmesg

Machine is the same as in bug report 28331 although with different software components: Acer Aspire L5100 with an AMD Athlon 64 X2 Dual Core Processor
4000+, this time running a 64 bits debian squeeze.

The machine is a small factor desktop machine designed around laptop
components, so the graphic card is an integrated radeon x1200.

When running a linux vanilla kernel 2.6.37-rc6, the screen flickers all the time
making the machine unusable, while with debian kernel 2.6.32-5  such "flick to black" event occur from time to time, making it annoying but usable.

While booting with radeon.modeset=0 the problem doesn't exhibits itself

The following packages version from debian squeeze are installed:
xserver-xorg                         1:7.5+8
xserver-xorg-core                    2:1.7.7-10
xserver-xorg-video-radeon            1:6.13.1-2+squeeze1

Please find attached Xorg.0.log, dmesg, register dumps for ums and kms for that machine (when booted on 2.6.37-rc6).

Regards,
Gildas
Comment 1 Gildas Le Nadan 2010-12-21 09:33:47 UTC
Created attachment 41345 [details]
Xorg.log
Comment 2 Gildas Le Nadan 2010-12-21 09:34:35 UTC
Created attachment 41346 [details] [review]
UMS register dump as per #28331
Comment 3 Gildas Le Nadan 2010-12-21 09:35:21 UTC
Created attachment 41347 [details] [review]
KMS register dump as per #28331
Comment 4 Gildas Le Nadan 2010-12-21 09:38:37 UTC
Created attachment 41348 [details] [review]
patch proposed by Alex Deucher

This patch, proposed by Alex on irc, applied with a drift of 20 lines or so did NOT fix the problem.
Comment 5 Alex Deucher 2010-12-21 10:51:07 UTC
How about this?

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..fa92120 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -521,12 +521,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        pll->flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
-               if ((rdev->family == CHIP_RS600) ||
-                   (rdev->family == CHIP_RS690) ||
-                   (rdev->family == CHIP_RS740))
-                       pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
-
                if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /* range limits??? */
                        pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
                else
Comment 6 Gildas Le Nadan 2010-12-21 11:37:15 UTC
(In reply to comment #5)
> How about this?
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index b0ab185..fa92120 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -521,12 +521,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>         pll->flags = 0;
> 
>         if (ASIC_IS_AVIVO(rdev)) {
> -               if ((rdev->family == CHIP_RS600) ||
> -                   (rdev->family == CHIP_RS690) ||
> -                   (rdev->family == CHIP_RS740))
> -                       pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
> -                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
> -
>                 if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /*
> range limits??? */
>                         pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
>                 else

No problem is still there. See register dump kms2.regs
Comment 7 Gildas Le Nadan 2010-12-21 11:37:51 UTC
Created attachment 41351 [details] [review]
after proposed patch #2 was applied
Comment 8 Alex Deucher 2010-12-22 11:26:01 UTC
Created attachment 41376 [details] [review]
add new pll flag

This patch adds a new pll flag to prefer slightly higher frequencies if the target clock cannot be hit exactly.
Comment 9 Alex Deucher 2010-12-22 11:28:24 UTC
With the patch from comment 8, try these possible fixes:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..0be8015 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))
                        pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
+                                      RADEON_PLL_PREFER_CLOSEST_HIGHER);
 
                if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /* range limits??? */
                        pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

Or:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..91facc8 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))
                        pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
+                                      RADEON_PLL_NO_ODD_POST_DIV);
 
                if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /* range limits??? */
                        pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
Comment 10 Gildas Le Nadan 2010-12-22 13:45:40 UTC
Created attachment 41379 [details]
patch+RADEON_PLL_PREFER_CLOSEST_HIGHER

registers for kms with new pll patch applied + RADEON_PLL_PREFER_CLOSEST_HIGHER

Screen flickers slightly less than previously but is still unusable
Comment 11 Gildas Le Nadan 2010-12-22 13:47:35 UTC
Created attachment 41380 [details]
patch + RADEON_PLL_NO_ODD_POST_DIV

registers for kms with new pll patch applied + RADEON_PLL_NO_ODD_POST_DIV

Screen flickers slightly less than without patch but is still unusable
Comment 12 Gildas Le Nadan 2010-12-22 13:48:56 UTC
(In reply to comment #9)
> With the patch from comment 8, try these possible fixes:
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index b0ab185..0be8015 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>                     (rdev->family == CHIP_RS690) ||
>                     (rdev->family == CHIP_RS740))
>                         pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
> -                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
> +                                      RADEON_PLL_PREFER_CLOSEST_HIGHER);
> 
>                 if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /*
> range limits??? */
>                         pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
> 
> Or:
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index b0ab185..91facc8 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>                     (rdev->family == CHIP_RS690) ||
>                     (rdev->family == CHIP_RS740))
>                         pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
> -                                      RADEON_PLL_PREFER_CLOSEST_LOWER);
> +                                      RADEON_PLL_NO_ODD_POST_DIV);
> 
>                 if (ASIC_IS_DCE32(rdev) && mode->clock > 200000)        /*
> range limits??? */
>                         pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

None of the proposed solutions fix the problem for good although there is some improvement over the flickering frequency.
Comment 13 Alex Deucher 2010-12-23 10:49:28 UTC
How about:

pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER);

Can you also attach a copy of your vbios?
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 14 Alex Deucher 2010-12-23 11:07:39 UTC
Also try:

pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
               RADEON_PLL_PREFER_CLOSEST_HIGHER |
               RADEON_PLL_NO_ODD_POST_DIV);
Comment 15 Gildas Le Nadan 2010-12-23 23:29:12 UTC
Created attachment 41406 [details]
vbios.rom

Here for Xmas, have a poodle vbios
Comment 16 Gildas Le Nadan 2010-12-23 23:50:31 UTC
(In reply to comment #13)
> How about:
> 
> pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER);
> 
> Can you also attach a copy of your vbios?
> (as root)
> (use lspci to get the bus id)
> cd /sys/bus/pci/devices/<pci bus id>
> echo 1 > rom
> cat rom > /tmp/vbios.rom
> echo 0 > rom

With this one screen is completely unusable (similar to the initial situation). Will attach kms_frac_closest.regs
Comment 17 Gildas Le Nadan 2010-12-23 23:51:50 UTC
Created attachment 41407 [details]
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER
Comment 18 Gildas Le Nadan 2010-12-24 00:10:58 UTC
(In reply to comment #14)
> Also try:
> 
> pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
>                RADEON_PLL_PREFER_CLOSEST_HIGHER |
>                RADEON_PLL_NO_ODD_POST_DIV);

No image at all with this one. See kms_frac_closest_odd.regs
Comment 19 Gildas Le Nadan 2010-12-24 00:11:54 UTC
Created attachment 41408 [details]
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV
Comment 20 Alex Deucher 2010-12-24 10:42:16 UTC
Created attachment 41430 [details] [review]
adjust up the clock slightly on rs6xx TDMS

Does this patch help?
Comment 21 Gildas Le Nadan 2011-01-08 15:34:32 UTC
(In reply to comment #20)
> Created an attachment (id=41430) [details]
> adjust up the clock slightly on rs6xx TDMS
> 
> Does this patch help?

This patch seems to help when combined with "RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV".

For now after a single session of 2h, it even seems more stable than ums (where occasional losses of images happen maybe every 20-30mins on average).

I've tried other combinations as well with various success:

- RADEON_PLL_PREFER_CLOSEST_LOWER => unstable-ish
- RADEON_PLL_USE_FRAC_FB_DIV => black
- RADEON_PLL_PREFER_CLOSEST_LOWER | RADEON_PLL_USE_FRAC_FB_DIV => not very stable
- RADEON_PLL_PREFER_CLOSEST_HIGHER => not stable
- RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER => not stable

I can provide the registers for the different tests if that could be of any uses.
Comment 22 Alex Deucher 2011-01-09 00:30:46 UTC
You might also try making slight changes to the clock adjustment:
adjusted_clock += 50;
e.g., try 40, 45, 55, 60, 65, etc.
Comment 23 Gildas Le Nadan 2011-01-10 01:51:20 UTC
(In reply to comment #22)
> You might also try making slight changes to the clock adjustment:
> adjusted_clock += 50;
> e.g., try 40, 45, 55, 60, 65, etc.

As far as I can tell the problem seems to be solved with adjusted_clock += 50; and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV.

After 3 hours of use (including watching video), 1 reboot and 1 cold boot, the screen never flicked, which not only means the bug concerned by this bug report is fixed, but apparently there is even an improvement over the previous situation.
Comment 24 Alex Deucher 2011-01-10 09:25:45 UTC
Created attachment 41852 [details] [review]
ppll stability fixes for rs690

I've sent this patch and the one from attachment 41376 [details] [review] to Dave.
Comment 25 Alex Deucher 2011-01-10 13:11:33 UTC
re-opening as there are still some issues as we discussed on IRC.
Comment 26 Gildas Le Nadan 2011-01-10 13:14:17 UTC
(In reply to comment #25)
> re-opening as there are still some issues as we discussed on IRC.

After our discussion on IRC caused by the fact your patch was slightly different than what I've tested, I've done the following tests:

1) DVI LCD screen VIEWSONIC 1680x1050 with DVI-DVI
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050      60.0 +
   1400x1050      60.0  
   1280x1024      75.0    60.0  
   1440x900       59.9  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
   640x400        70.0 

OK   1680x1050 1280x1024 832x624 800x600 720x400
unstable   1400x1050 640x480 640x400
KO	1440x900 1280x960 1152x864 1024x768

2) LCD screen IIYAMA 1920x1200  with HDMI connector on HDMI
Screen 0: minimum 320 x 200, current 640 x 480, maximum 8192 x 8192
DVI-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 640x480+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1920x1200      60.0 +
   1680x1050      60.0 +
   1600x1200      60.0  
   1280x1024      76.0     75.0     72.0     60.0  
   1440x900       75.0     59.9  
   1152x864       75.0  
   1280x720       60.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  

KO except below 832x624. With 800x600, the image contain noise (flickering horizontal color lines).

/!\ when connecting the VIEWSONIC with a HDMI-DVI cable, results are similar, i-e no image except below 832x624.

3) ANALOG screen SILICON GRAPHICS connected on DVI with VGA adapter 
DVI-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 350mm x 280mm
   1280x1024      75.0  
   1024x768       75.1

OK for both resolutions
Comment 27 Daniel 2011-01-12 07:14:30 UTC
I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. 

But my computer NOT starts directly flickering after kernel modesetting is initialized. It starts after performing some cpu usage like compiling. First there are many white lines flickering at the screen, then the screen going black.

Flickering Video: http://youtu.be/oKsQ4Ga1pKA

I have IBM Thinkpad T60 / Gentoo Linux
with ATI Technologies Inc Radeon Mobility X1400
Comment 28 Alex Deucher 2011-01-12 08:51:01 UTC
(In reply to comment #27)
> I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the
> problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. 

new_pll=0 became the default.
Comment 29 Daniel 2011-01-12 10:22:38 UTC
Okay, but without new_pll=0 in 2.6.35/36 i had the completely identical error.
Comment 30 Alex Deucher 2011-01-12 17:01:16 UTC
Created attachment 41943 [details] [review]
possible fix

Does this patch fix the issues?
Comment 31 Gildas Le Nadan 2011-08-05 08:59:00 UTC
Hi, I've compiled kernel 3.0 and apparently things are way better now.

Connection on the viewsonic using dvi seem to be stable for all definitions. I'll confirm after a few days using 1680x1050.

Vga connection to the analog SGI screen seem OK too.

On the Iiyama 24" with the HDMI attachment, I have noted the "turn black 3 secs and display image again" syndrom is still there though (I'd say once every 5-!0 mn on average).

Gildas
Comment 32 Martin Peres 2019-11-20 08:02:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/966.

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.