Bug 25741

Summary: [R600/KMS] external display flickering
Product: DRI Reporter: Luca Tettamanti <kronos.it>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: bryce, pclaves
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Kernel log for 2.6.32 (working)
none
Kernel log for 2.6.33-rc1 (flickering)
none
xrandr output with 2.6.32
none
xrandr output with 2.6.33-rc1
none
Xorg output with 2.6.32
none
Xorg output with 2.6.33-rc1
none
M76 video BIOS
none
add missing breaks
none
Add a module parameter to disable spread spectrum unconditionally
none
dmesg with 2.6.33 KMS enabled
none
Xorg log with Kernel 2.6.33 KMS
none
possible fix
none
fix spread spectrum none

Description Luca Tettamanti 2009-12-21 03:36:36 UTC
With kernel 2.6.33-rc1 and KMS enabled, the image on the external display (VGA) is disported by a kind of ripple effect. This happens as soon fbcon kicks in, before even starting Xorg.
At boot the external monitor is set to clone the internal display, but even after starting X and setting to it's native resolution it's still flickering.
Not sure that's relevant: with 2.6.33-rc1 xrandr does not report any EDID for the LVDS.
I'm attaching kernel and xorg logs, and the output of xrandr.
Comment 1 Luca Tettamanti 2009-12-21 03:37:12 UTC
Created attachment 32218 [details]
Kernel log for 2.6.32 (working)
Comment 2 Luca Tettamanti 2009-12-21 03:37:37 UTC
Created attachment 32219 [details]
Kernel log for 2.6.33-rc1 (flickering)
Comment 3 Luca Tettamanti 2009-12-21 03:38:05 UTC
Created attachment 32220 [details]
xrandr output with 2.6.32
Comment 4 Luca Tettamanti 2009-12-21 03:38:18 UTC
Created attachment 32221 [details]
xrandr output with 2.6.33-rc1
Comment 5 Luca Tettamanti 2009-12-21 03:38:50 UTC
Created attachment 32222 [details]
Xorg output with 2.6.32
Comment 6 Luca Tettamanti 2009-12-21 03:39:05 UTC
Created attachment 32223 [details]
Xorg output with 2.6.33-rc1
Comment 7 Alex Deucher 2009-12-21 08:04:35 UTC
There are actually two bugs here:

1. missing edid on lvds

It appears we are selecting a different i2c line in 2.6.33. I think I know where the problem is. Can you attach your video bios?  (as root):
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

2. flickering on VGA

Does loading radeon with new_pll=1 fix this problem?
Comment 8 Luca Tettamanti 2009-12-21 13:51:11 UTC
Created attachment 32230 [details]
M76 video BIOS
Comment 9 Luca Tettamanti 2009-12-21 13:55:38 UTC
(In reply to comment #7)
> There are actually two bugs here:
> 
> 1. missing edid on lvds
> 
> It appears we are selecting a different i2c line in 2.6.33. I think I know
> where the problem is. Can you attach your video bios?  (as root):

Attached.

> 2. flickering on VGA
> 
> Does loading radeon with new_pll=1 fix this problem?

It's enabled by default. Will try with 0.
Comment 10 Luca Tettamanti 2009-12-22 08:57:47 UTC
new_pll=0 does not work. This is the internal panel:

-[drm:radeon_compute_pll_avivo], 71000 84.1, 2, 16
+[drm:radeon_compute_pll], PLL freq 71000 2 1023
 executing set pll
 executing set crtc timing
 [drm] LVDS-13: set mode 1280x800 2e

and this is the external monitor (different one, since I'm at home)

-[drm:radeon_compute_pll_avivo], 108000 88.0, 2, 11
+[drm:radeon_compute_pll], PLL freq 108000 2 1023
 executing set pll
 executing set crtc timing
 [drm] TV-9: set mode 1280x1024 2d

Visual result is the same. For reference 2.6.32 says:

[drm:radeon_compute_pll], PLL freq 108000 2 1023
executing set pll
executing set crtc timing
[drm] TV-9: set mode 1280x1024 2e

[drm:radeon_compute_pll], PLL freq 71000 2 1023
executing set pll
executing set crtc timing
[drm] LVDS-13: set mode 1280x800 2f

I can attached the complete logs with debug enabled if needed.
Comment 11 Luca Tettamanti 2009-12-28 02:41:49 UTC
I've bisected both problems.

The flickering is causes by:

279b215ecb8acc735c01ac89b1aa28c4a27dcafa is the first bad commit
commit 279b215ecb8acc735c01ac89b1aa28c4a27dcafa                 
Author: Alex Deucher <alexdeucher@gmail.com>                    
Date:   Tue Dec 8 14:07:03 2009 -0500                           

    drm/radeon/kms: make sure ss id matches

    entries in the ss table aren't always ordered
    by id.

    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

While the missing EDID on LVDS points to:

d3f420d1089169fb48366e1aa750bdd92db0a04b is the first bad commit
commit d3f420d1089169fb48366e1aa750bdd92db0a04b                 
Author: Alex Deucher <alexdeucher@gmail.com>                    
Date:   Tue Dec 8 14:30:49 2009 -0500                           

    drm/radeon/kms: make sure i2c id matches

    Entries in the i2c table aren't always ordered
    by id.  This allows us to remove some quirks
    that are no longer needed.

    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
Comment 12 Alex Deucher 2009-12-28 10:47:29 UTC
Created attachment 32336 [details] [review]
add missing breaks

This patch should fix it.
Comment 13 Luca Tettamanti 2009-12-29 02:48:46 UTC
(In reply to comment #12)
> Created an attachment (id=32336) [details]
> add missing breaks
> 
> This patch should fix it.

The EDID is back, the flickering is still there, but I think I see the problem.
The old code used "id" as offset into the asSS_Info array; now this is the PPLL_SS_Info table on my M76:

data_table  0000ae26  #12  (PPLL_SS_Info):

  Size         000c
  Format Rev.  01
  Param Rev.   00
  Content Rev. 02

  00000000:            1e00 0101  2a01 0202                   ....*...

  0000:  ATOM_COMMON_TABLE_HEADER sHeader                    :
    0000:  USHORT usStructureSize                              = 0x000c     (12)
    0002:  UCHAR ucTableFormatRevision                         = 0x01       (1)
    0003:  UCHAR ucTableContentRevision                        = 0x02       (2)
  0004:  ATOM_SPREAD_SPECTRUM_ASSIGNMENT asSS_Info       [0] :
    0004:  USHORT usSpreadSpectrumPercentage                   = 0x001e     (30)
    0006:  UCHAR ucSpreadSpectrumType                          = 0x01       (1)
    0007:  UCHAR ucSS_Step                                     = 0x01       (1)
    0008:  UCHAR ucSS_Delay                                    = 0x2a       (42)
    0009:  UCHAR ucSS_Id                                       = 0x01       (1)
    000a:  UCHAR ucRecommandedRef_Div                          = 0x02       (2)
    000b:  UCHAR ucSS_Range                                    = 0x02       (2)
[cut]

Note that the size is 12 bytes, so there's only one ATOM_SPREAD_SPECTRUM_ASSIGNMENT; ucSS_Id in the LVDS block is 0x1 and the old code ended up reading past the end of array. For example now it's trying to set:

[   37.652741]   usSpreadSpectrumPercentage = 0xf8
[   37.652783]   ucSpreadSpectrumType       = 0x1
[   37.652824]   ucSS_Step                  = 0x2
[   37.652867]   ucSS_Delay                 = 0xf
[   37.652910]   ucSS_Range                 = 0x0
[   37.652953]   ucRecommendedRef_Div       = 0x3c

I guess that atombios validates the data and discards it. The new code picks up the correct data... and causes flickering. Why is this causing flickering on the _external_ display? I'm not sure what happens at boot when the outputs are cloned, but with X running the outputs are "uncloned" and are using different CRTCs; the kernel module enables SS on CRTC 1, and xrandr reports that it's used by LVDS.
Comment 14 Luca Tettamanti 2010-01-07 09:00:06 UTC
Created attachment 32509 [details] [review]
Add a module parameter to disable spread spectrum unconditionally

In case this turns out to be a bug in my card bios or a hardware problem; it's really a show-stopper for me.
Comment 15 Philipp Claves 2010-03-06 07:56:45 UTC
I have the same VGA ripple effect.

01:00.0 VGA compatible controller: ATI Technologies Inc M76 [Radeon Mobility HD 2600 Series]

agd5f on IRC suggested to try 'avivotool regset 0x458 0x00000000' or 'avivotool regset 0x45c 0x00000000'. The first command fixes it (didn't try the second one).

avivotool is a part of radeontool and can be found here: http://cgit.freedesktop.org/~airlied/radeontool
Comment 16 Philipp Claves 2010-03-06 07:58:07 UTC
Created attachment 33815 [details]
dmesg with 2.6.33 KMS enabled
Comment 17 Philipp Claves 2010-03-06 07:59:25 UTC
Created attachment 33816 [details]
Xorg log with Kernel 2.6.33 KMS
Comment 18 Alex Deucher 2010-03-06 08:06:50 UTC
Created attachment 33817 [details] [review]
possible fix

Does this patch help?
Comment 19 Luca Tettamanti 2010-03-08 05:00:29 UTC
(In reply to comment #18)
> Created an attachment (id=33817) [details]
> possible fix
> 
> Does this patch help?

No. However fiddling with avivotool as suggested by Philipp fixes the issue.
From the output of the tool it seems that the kernel driver is setting the wrong (PLL id swapped?) register:

#. /avivotool regset 0x458 0x00000000
OLD: 0x458 (0458)       0x2a020101 (704774401)
NEW: 0x458 (0458)       0x00000000 (0)

# ./avivotool regset 0x45c 0x00000000
OLD: 0x45c (045c)       0x00000000 (0)
NEW: 0x45c (045c)       0x00000000 (0)

Setting 0x458 (AVIVO_P1PLL_INT_SS_CNTL) stops the flickering on the external VGA monitor.
Comment 20 Alex Deucher 2010-03-08 10:30:34 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > Created an attachment (id=33817) [details] [details]
> > possible fix
> > 
> > Does this patch help?
> 
> No. However fiddling with avivotool as suggested by Philipp fixes the issue.
> From the output of the tool it seems that the kernel driver is setting the
> wrong (PLL id swapped?) register:
> 
> #. /avivotool regset 0x458 0x00000000
> OLD: 0x458 (0458)       0x2a020101 (704774401)
> NEW: 0x458 (0458)       0x00000000 (0)
> 
> # ./avivotool regset 0x45c 0x00000000
> OLD: 0x45c (045c)       0x00000000 (0)
> NEW: 0x45c (045c)       0x00000000 (0)
> 
> Setting 0x458 (AVIVO_P1PLL_INT_SS_CNTL) stops the flickering on the external
> VGA monitor.
> 

Do things work properly if you boot without the VGA monitor attached and then connect and enable it later?
Comment 21 Philipp Claves 2010-03-08 10:43:02 UTC
(In reply to comment #20)
> Do things work properly if you boot without the VGA monitor attached and then
> connect and enable it later?
> 

Yes, this works for me.

Maybe this is related: When booting with UMS and VGA connected, the LVDS Panel is the first Monitor and VGA the second. With KMS it is the other way round.
Comment 22 Alex Deucher 2010-03-08 14:17:04 UTC
Created attachment 33870 [details] [review]
fix spread spectrum

This should do the trick.  Please apply this on top of the previous patch.
Comment 23 Luca Tettamanti 2010-03-09 01:50:32 UTC
(In reply to comment #22)
> Created an attachment (id=33870) [details]
> fix spread spectrum
> 
> This should do the trick.  Please apply this on top of the previous patch.

Works for me, thanks!
Comment 24 Alex Deucher 2010-03-09 06:16:16 UTC
Patch sent to Dave.
Comment 25 Alex Deucher 2010-03-23 18:45:50 UTC
*** Bug 27278 has been marked as a duplicate of this bug. ***

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.