Bug 25741

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. ***