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.
Created attachment 32218 [details] Kernel log for 2.6.32 (working)
Created attachment 32219 [details] Kernel log for 2.6.33-rc1 (flickering)
Created attachment 32220 [details] xrandr output with 2.6.32
Created attachment 32221 [details] xrandr output with 2.6.33-rc1
Created attachment 32222 [details] Xorg output with 2.6.32
Created attachment 32223 [details] Xorg output with 2.6.33-rc1
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?
Created attachment 32230 [details] M76 video BIOS
(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.
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.
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>
Created attachment 32336 [details] [review] add missing breaks This patch should fix it.
(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.
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.
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
Created attachment 33815 [details] dmesg with 2.6.33 KMS enabled
Created attachment 33816 [details] Xorg log with Kernel 2.6.33 KMS
Created attachment 33817 [details] [review] possible fix Does this patch help?
(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.
(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?
(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.
Created attachment 33870 [details] [review] fix spread spectrum This should do the trick. Please apply this on top of the previous patch.
(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!
Patch sent to Dave.
*** 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.