[Bug 48880] New: Set mode has different timings than requested on VGA

[Bug 48880] New: Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

             Bug #: 48880
           Summary: Set mode has different timings than requested on VGA
    Classification: Unclassified
           Product: DRI
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: tvrtko.ursulin@onelan.co.uk


AMD G-T56N (Radeon HD 6310) hardware with kernel 3.4-rc3 with a Xorg DDX from
28.03.2012. plus a tiling patch from bug 47765.

List of modes from X.org log:

[   933.174] (II) RADEON(0): Printing DDC gathered Modelines:
[   933.174] (II) RADEON(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052
2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[   933.174] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056 
600 601 605 628 +hsync +vsync (37.9 kHz)
[   933.174] (II) RADEON(0): Modeline "800x600"x0.0   36.00  800 824 896 1024 
600 601 603 625 +hsync +vsync (35.2 kHz)
[   933.174] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840 
480 481 484 500 -hsync -vsync (37.5 kHz)
[   933.174] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 664 704 832 
480 489 492 520 -hsync -vsync (37.9 kHz)
[   933.174] (II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864 
480 483 486 525 -hsync -vsync (35.0 kHz)
[   933.174] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800 
480 490 492 525 -hsync -vsync (31.5 kHz)
[   933.174] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900 
400 412 414 449 -hsync +vsync (31.5 kHz)
[   933.174] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
[   933.174] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136
1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[   933.174] (II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184
1328  768 771 777 806 -hsync -vsync (56.5 kHz)
[   933.174] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184
1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[   933.174] (II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152 
624 625 628 667 -hsync -vsync (49.7 kHz)
[   933.174] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056 
600 601 604 625 +hsync +vsync (46.9 kHz)
[   933.174] (II) RADEON(0): Modeline "800x600"x0.0   50.00  800 856 976 1040 
600 637 643 666 +hsync +vsync (48.1 kHz)
[   933.174] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344
1600  864 865 868 900 +hsync +vsync (67.5 kHz)
[   933.174] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920 2040 2248
2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz)
[   933.174] (II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960
2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
[   933.174] (II) RADEON(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856
2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
[   933.174] (II) RADEON(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672
1904  900 903 909 934 -hsync +vsync (55.9 kHz)
[   933.174] (II) RADEON(0): Modeline "1400x1050"x0.0  121.75  1400 1488 1632
1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz)
[   933.174] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[   933.174] (II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488
1800  960 961 964 1000 +hsync +vsync (60.0 kHz)

Our application requests (via XRRSetCrtcConfig) the 1920x1080 with a 148.5 MHz
dot clock (which comes from monitors EDID).

xrandr --verbose shows this is the set and active mode.

However monitor says it is running with 175.9 MHz dot clock and can't adjust to
that signal.

Monitor data from EDID:

[  1312.412] (II) RADEON(0): EDID for output DVI-0
[  1312.412] (II) RADEON(0): Manufacturer: VSC  Model: fc21  Serial#: 16843009
[  1312.412] (II) RADEON(0): Year: 2009  Week: 24
[  1312.412] (II) RADEON(0): EDID Version: 1.3
[  1312.412] (II) RADEON(0): Analog Display Input,  Input Voltage Level:
0.700/0.300 V
[  1312.412] (II) RADEON(0): Sync:  Separate  Composite  SyncOnGreen
[  1312.412] (II) RADEON(0): Max Image Size [cm]: horiz.: 48  vert.: 27
[  1312.412] (II) RADEON(0): Gamma: 2.20
[  1312.412] (II) RADEON(0): DPMS capabilities: Off; RGB/Color Display
[  1312.412] (II) RADEON(0): Default color space is primary color space
[  1312.412] (II) RADEON(0): First detailed timing is preferred mode
[  1312.412] (II) RADEON(0): redX: 0.648 redY: 0.339   greenX: 0.282 greenY:
0.603
[  1312.412] (II) RADEON(0): blueX: 0.143 blueY: 0.070   whiteX: 0.313 whiteY:
0.329
[  1312.412] (II) RADEON(0): Supported established timings:
[  1312.412] (II) RADEON(0): 720x400@70Hz
[  1312.412] (II) RADEON(0): 640x480@60Hz
[  1312.412] (II) RADEON(0): 640x480@67Hz
[  1312.412] (II) RADEON(0): 640x480@72Hz
[  1312.412] (II) RADEON(0): 640x480@75Hz
[  1312.412] (II) RADEON(0): 800x600@56Hz
[  1312.412] (II) RADEON(0): 800x600@60Hz
[  1312.412] (II) RADEON(0): 800x600@72Hz
[  1312.412] (II) RADEON(0): 800x600@75Hz
[  1312.413] (II) RADEON(0): 832x624@75Hz
[  1312.413] (II) RADEON(0): 1024x768@60Hz
[  1312.413] (II) RADEON(0): 1024x768@70Hz
[  1312.413] (II) RADEON(0): 1024x768@75Hz
[  1312.413] (II) RADEON(0): 1280x1024@75Hz
[  1312.413] (II) RADEON(0): 1152x864@75Hz
[  1312.413] (II) RADEON(0): Manufacturer's mask: 0
[  1312.413] (II) RADEON(0): Supported standard timings:
[  1312.413] (II) RADEON(0): #0: hsize: 1920  vsize 1080  refresh: 60  vid:
49361
[  1312.413] (II) RADEON(0): #1: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[  1312.413] (II) RADEON(0): #2: hsize: 1600  vsize 1200  refresh: 60  vid:
16553
[  1312.413] (II) RADEON(0): #3: hsize: 1440  vsize 900  refresh: 60  vid: 149
[  1312.413] (II) RADEON(0): #4: hsize: 1400  vsize 1050  refresh: 60  vid:
16528
[  1312.413] (II) RADEON(0): #5: hsize: 1280  vsize 1024  refresh: 60  vid:
32897
[  1312.413] (II) RADEON(0): #6: hsize: 1280  vsize 960  refresh: 60  vid:
16513
[  1312.413] (II) RADEON(0): #7: hsize: 1152  vsize 864  refresh: 75  vid:
20337
  1312.413] (II) RADEON(0): Supported detailed timing:
[  1312.413] (II) RADEON(0): clock: 148.5 MHz   Image Size:  477 x 268 mm
[  1312.413] (II) RADEON(0): h_active: 1920  h_sync: 2008  h_sync_end 2052
h_blank_end 2200 h_border: 0
[  1312.413] (II) RADEON(0): v_active: 1080  v_sync: 1084  v_sync_end 1089
v_blanking: 1125 v_border: 0
[  1312.413] (II) RADEON(0): Serial No: R2S092421011
[  1312.413] (II) RADEON(0): Ranges: V min: 50 V max: 75 Hz, H min: 24 H max:
82 kHz, PixClock max 215 MHz
[  1312.413] (II) RADEON(0): Monitor name: VX2260WM
[  1312.413] (II) RADEON(0): EDID (in hex):
[  1312.413] (II) RADEON(0):    00ffffffffffff005a6321fc01010101
[  1312.413] (II) RADEON(0):    181301030e301b782e3585a656489a24
[  1312.414] (II) RADEON(0):    125054bfef80d1c0b300a94095009040
[  1312.414] (II) RADEON(0):    81808140714f023a801871382d40582c
[  1312.414] (II) RADEON(0):    4500dd0c1100001e000000ff00523253
[  1312.414] (II) RADEON(0):    3039323432313031310a000000fd0032
[  1312.414] (II) RADEON(0):    4b185215000a202020202020000000fc
[  1312.414] (II) RADEON(0):    00565832323630574d0a202020200072
[  1312.414] (II) RADEON(0): Not using mode "1280x1024" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "1152x864" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "1024x768" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "1024x768" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "832x624" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "800x600" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "800x600" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "800x600" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "640x480" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "640x480" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "640x480" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Not using mode "720x400" (vrefresh out of range)
[  1312.414] (II) RADEON(0): Printing probed modes for output DVI-0
[  1312.414] (II) RADEON(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052
2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[  1312.414] (II) RADEON(0): Modeline "1600x1200"x60.0  162.00  1600 1664 1856
2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
[  1312.414] (II) RADEON(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960
2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
[  1312.415] (II) RADEON(0): Modeline "1400x1050"x60.0  121.75  1400 1488 1632
1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz)
[  1312.415] (II) RADEON(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[  1312.415] (II) RADEON(0): Modeline "1440x900"x59.9  106.50  1440 1520 1672
1904  900 903 909 934 -hsync +vsync (55.9 kHz)
[  1312.415] (II) RADEON(0): Modeline "1280x960"x60.0  108.00  1280 1376 1488
1800  960 961 964 1000 +hsync +vsync (60.0 kHz)
[  1312.415] (II) RADEON(0): Modeline "NTB-vesa_cvt-1360x768"x59.8   84.75 
1360 1432 1568 1776  768 771 781 798 -hsync +vsync (47.7 kHz)
[  1312.415] (II) RADEON(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184
1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[  1312.415] (II) RADEON(0): Modeline "800x600"x60.3   40.00  800 840 968 1056 
600 601 605 628 +hsync +vsync (37.9 kHz)
[  1312.415] (II) RADEON(0): Modeline "Fallback"x60.0   25.20  640 656 752 800 
480 490 492 525 -hsync -vsync (31.5 kHz)
[  1312.415] (II) RADEON(0): Modeline "640x480"x60.0   25.20  640 656 752 800 
480 490 492 525 -hsync -vsync (31.5 kHz)

Another modelist later on:

[  1313.340] (II) RADEON(0): EDID vendor "VSC", prod id 64545
[  1313.340] (II) RADEON(0): Using hsync ranges from config file
[  1313.340] (II) RADEON(0): Using vrefresh ranges from config file
[  1313.340] (II) RADEON(0): Printing DDC gathered Modelines:
[  1313.340] (II) RADEON(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052
2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056 
600 601 605 628 +hsync +vsync (37.9 kHz)
[  1313.340] (II) RADEON(0): Modeline "800x600"x0.0   36.00  800 824 896 1024 
600 601 603 625 +hsync +vsync (35.2 kHz)
[  1313.340] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840 
480 481 484 500 -hsync -vsync (37.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 664 704 832 
480 489 492 520 -hsync -vsync (37.9 kHz)
[  1313.340] (II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864 
480 483 486 525 -hsync -vsync (35.0 kHz)
[  1313.340] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800 
480 490 492 525 -hsync -vsync (31.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900 
400 412 414 449 -hsync +vsync (31.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
[  1313.340] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136
1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[  1313.340] (II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184
1328  768 771 777 806 -hsync -vsync (56.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184
1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[  1313.340] (II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152 
624 625 628 667 -hsync -vsync (49.7 kHz)
[  1313.340] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056 
600 601 604 625 +hsync +vsync (46.9 kHz)
[  1313.340] (II) RADEON(0): Modeline "800x600"x0.0   50.00  800 856 976 1040 
600 637 643 666 +hsync +vsync (48.1 kHz)
[  1313.340] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344
1600  864 865 868 900 +hsync +vsync (67.5 kHz)
[  1313.340] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920 2040 2248
2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz)
[  1313.340] (II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960
2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
[  1313.340] (II) RADEON(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856
2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
[  1313.340] (II) RADEON(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672
1904  900 903 909 934 -hsync +vsync (55.9 kHz)
[  1313.341] (II) RADEON(0): Modeline "1400x1050"x0.0  121.75  1400 1488 1632
1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz)
[  1313.341] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[  1313.341] (II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488
1800  960 961 964 1000 +hsync +vsync (60.0 kHz)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #1 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:07:47 PDT ---
Kernel view of the modelines:

[ 1749.396456] [drm:drm_mode_debug_printmodeline], Modeline 18:"1920x1080" 60
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[ 1749.396472] [drm:drm_mode_debug_printmodeline], Modeline 22:"1600x1200" 60
162000 1600 1664 1856 2160 1200 1201 1204 1250 0x40 0x5
[ 1749.396488] [drm:drm_mode_debug_printmodeline], Modeline 19:"1680x1050" 60
146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6
[ 1749.396504] [drm:drm_mode_debug_printmodeline], Modeline 24:"1400x1050" 60
121750 1400 1488 1632 1864 1050 1053 1057 1089 0x40 0x6
[ 1749.396519] [drm:drm_mode_debug_printmodeline], Modeline 36:"1280x1024" 75
135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[ 1749.396534] [drm:drm_mode_debug_printmodeline], Modeline 25:"1280x1024" 60
108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[ 1749.396549] [drm:drm_mode_debug_printmodeline], Modeline 23:"1440x900" 60
106500 1440 1520 1672 1904 900 903 909 934 0x40 0x6
[ 1749.396564] [drm:drm_mode_debug_printmodeline], Modeline 26:"1280x960" 60
108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[ 1749.396579] [drm:drm_mode_debug_printmodeline], Modeline 43:"1152x864" 75
108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
[ 1749.396594] [drm:drm_mode_debug_printmodeline], Modeline 37:"1024x768" 75
78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[ 1749.396609] [drm:drm_mode_debug_printmodeline], Modeline 38:"1024x768" 70
75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[ 1749.396624] [drm:drm_mode_debug_printmodeline], Modeline 39:"1024x768" 60
65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[ 1749.396638] [drm:drm_mode_debug_printmodeline], Modeline 40:"832x624" 75
57284 832 864 928 1152 624 625 628 667 0x40 0xa
[ 1749.396654] [drm:drm_mode_debug_printmodeline], Modeline 42:"800x600" 72
50000 800 856 976 1040 600 637 643 666 0x40 0x5
[ 1749.396669] [drm:drm_mode_debug_printmodeline], Modeline 41:"800x600" 75
49500 800 816 896 1056 600 601 604 625 0x40 0x5
[ 1749.396683] [drm:drm_mode_debug_printmodeline], Modeline 29:"800x600" 60
40000 800 840 968 1056 600 601 605 628 0x40 0x5
[ 1749.396698] [drm:drm_mode_debug_printmodeline], Modeline 30:"800x600" 56
36000 800 824 896 1024 600 601 603 625 0x40 0x5
[ 1749.396712] [drm:drm_mode_debug_printmodeline], Modeline 32:"640x480" 73
31500 640 664 704 832 480 489 491 520 0x40 0xa
[ 1749.396770] [drm:drm_mode_debug_printmodeline], Modeline 31:"640x480" 75
31500 640 656 720 840 480 481 484 500 0x40 0xa
[ 1749.396798] [drm:drm_mode_debug_printmodeline], Modeline 33:"640x480" 67
30240 640 704 768 864 480 483 486 525 0x40 0xa
[ 1749.396824] [drm:drm_mode_debug_printmodeline], Modeline 34:"640x480" 60
25200 640 656 752 800 480 490 492 525 0x40 0xa
[ 1749.396850] [drm:drm_mode_debug_printmodeline], Modeline 35:"720x400" 70
28320 720 738 846 900 400 412 414 449 0x40 0x6

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #2 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:08:39 PDT ---
I've tried setting a handful of other resolutions via the xrandr tool and in
all cases monitors reported clock matches the above list. Only 1920x1080 seems
broken.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #3 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:18:54 PDT ---

Some debug showing the modeset itself:

[ 2405.577713] [drm:drm_crtc_helper_set_config], modes are different, full mode
set
[ 2405.577721] [drm:drm_mode_debug_printmodeline], Modeline 28:"" 0 40000 800
840 968 1056 600 601 605 628 0x0 0x5
[ 2405.577737] [drm:drm_mode_debug_printmodeline], Modeline 27:"" 0 148500 1920
2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[ 2405.577754] [drm:drm_crtc_helper_set_config], [CONNECTOR:15:DVI-I-1] to
[CRTC:10]
[ 2405.577764] [drm:drm_crtc_helper_set_config], attempting to set mode from
userspace
[ 2405.577772] [drm:drm_mode_debug_printmodeline], Modeline 27:"" 0 148500 1920
2008 2052 2200 1080 1084 1089 1125 0x0 0x5
[ 2405.577787] > drm_crtc_helper_set_mode
[ 2405.577796] [drm:radeon_encoder_set_active_device], setting active device to
00000001 from 00000001 00000081 for encoder 4
[ 2405.577812] [drm:drm_crtc_helper_set_mode], [CRTC:10]
[ 2405.577822] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3,
devices 00000001, active_devices 00000001
[ 2405.577867] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3,
devices 00000008, active_devices 00000000
[ 2405.577879] > radeon_atom_encoder_dpms_dig 3
[ 2405.577886] - radeon_atom_encoder_dpms_dig
[ 2405.577893] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3,
devices 00000080, active_devices 00000000
[ 2405.577935] > radeon_atom_encoder_dpms_dig 3
[ 2405.577946] - radeon_atom_encoder_dpms_dig
[ 2405.577968] > atombios_crtc_dpms 3
[ 2405.577984] [drm:evergreen_irq_set], evergreen_irq_set: vblank 0
[ 2405.577998] [drm:evergreen_irq_set], evergreen_irq_set: vblank 1
[ 2405.578013] [drm:evergreen_irq_set], evergreen_irq_set: hpd 1
[ 2405.578027] [drm:evergreen_irq_set], evergreen_irq_set: hpd 2
[ 2405.578043] [drm:drm_vblank_get], enabling vblank on crtc 0, ret: 0
[ 2405.578061] [drm:evergreen_irq_process], 
[ 2405.578071] [drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 0 : v 5
p(555,248)@ 1334762036.373002 -> 1334762036.366440 [e 3 us, 0 rep]
[ 2405.578093] [drm:drm_update_vblank_count], r600_irq_process start: rptr
11728, wptr 11744
[ 2405.578107] enabling vblank interrupts on crtc 0, missed 642
[ 2405.578120] [drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 0 : v 5
p(776,250)@ 1334762036.373061 -> 1334762036.366441 [e 3 us, 0 rep]
[ 2405.578129] [drm:drm_handle_vblank], crtc 0: Redundant vblirq ignored.
diff_ns = 1000
[ 2405.578136] [drm:evergreen_irq_process], IH: D1 vblank
[ 2405.587260] [drm:evergreen_irq_process], r600_irq_process start: rptr 11744,
wptr 11760
[ 2405.587281] [drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 0 : v 13
p(14,598)@ 1334762036.382228 -> 1334762036.383019 [e 2 us, 0 rep]
[ 2405.587290] [drm:evergreen_irq_process], IH: D1 vblank
[ 2405.587371] - atombios_crtc_dpms
[ 2405.587390] [drm:radeon_compute_pll_avivo], 14843, pll dividers - fb: 95.0
ref: 8, post 8
[ 2405.592134] [drm:evergreen_program_watermarks], force priority to high
[ 2405.592156] [drm:drm_crtc_helper_set_mode], [ENCODER:16:TV-16] set
[MODE:27:]
[ 2405.592199] > atombios_crtc_dpms 0
[ 2405.592218] [drm:dce4_crtc_load_lut], 0
[ 2405.592244] - atombios_crtc_dpms
[ 2405.592256] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 0,
devices 00000001, active_devices 00000001
[ 2405.592267] [drm:drm_calc_timestamping_constants], crtc 10: hwmode: htotal
2200, vtotal 1125, vdisplay 1080
[ 2405.592273] [drm:drm_calc_timestamping_constants], crtc 10: clock 148500 kHz
framedur 16665750 linedur 14814, pixeldur 6
[ 2405.592280] - drm_crtc_helper_set_mode
[ 2405.592283] [drm:drm_crtc_helper_set_config], Setting connector DPMS state
to on
[ 2405.592287] [drm:drm_crtc_helper_set_config],        [CONNECTOR:15:DVI-I-1]
set DPMS on
[ 2405.592292] > drm_helper_connector_dpms 0 (current: 0)
[ 2405.592296] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3,
devices 00000008, active_devices 00000000
[ 2405.592301] > radeon_atom_encoder_dpms_dig 3
[ 2405.592305] - radeon_atom_encoder_dpms_dig
[ 2405.592308] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3,
devices 00000080, active_devices 00000000
[ 2405.592313] > radeon_atom_encoder_dpms_dig 3
[ 2405.592316] - radeon_atom_encoder_dpms_dig
[ 2405.592320] > atombios_crtc_dpms 3
[ 2405.592334] - atombios_crtc_dpms
[ 2405.592343] [drm:drm_ioctl], pid=1628, cmd=0xc01064ab, nr=0xab, dev 0xe200,
auth=1
[ 2405.592350] > drm_helper_connector_dpms 0 (current: 0)
[ 2405.592565] [drm:drm_ioctl], pid=1628, cmd=0xc01c64a3, nr=0xa3, dev 0xe200,
auth=1
[ 2405.592571] [drm:radeon_crtc_cursor_move], x 806 y 547 c->x 0 c->y 0
[ 2405.592586] [drm:drm_ioctl], pid=1628, cmd=0xc01064ab, nr=0xab, dev 0xe200,
auth=1
[ 2405.592592] > drm_helper_connector_dpms 3 (current: 3)
[ 2405.608834] [drm:evergreen_irq_process], r600_irq_process start: rptr 11760,
wptr 11776
[ 2405.608863] [drm:drm_calc_vbltimestamp_from_scanoutpos], crtc 0 : v 7
p(195,-45)@ 1334762036.403820 -> 1334762036.404485 [e 3 us, 0 rep]
[ 2405.608881] [drm:evergreen_irq_process], IH: D1 vblank

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #4 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:25:15 PDT ---
So it all looks right (pixel clock wise) in radeon_compute_pll_avivo. I guess
atombios_crtc_set_pll calls atombios_crtc_program_ss to program the hardware.
Could things be going wrong there?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #5 from Alex Deucher <agd5f@yahoo.com> 2012-04-18 08:25:53 PDT ---
If you manually add the 1920x1080 modeline with xrandr, does it work ok?

E.g.,

xrandr --newmode "my1920x1080"  148.50  1920 2008 2052 2200  1080 1084 1089
1125 +hsync +vsync
xrandr --addmode DVI-0 "my1920x1080"
xrandr --output DVI-0 --mode "my1920x1080"

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #6 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:34:44 PDT ---
(In reply to comment #5)
> If you manually add the 1920x1080 modeline with xrandr, does it work ok?
> 
> E.g.,
> 
> xrandr --newmode "my1920x1080"  148.50  1920 2008 2052 2200  1080 1084 1089
> 1125 +hsync +vsync
> xrandr --addmode DVI-0 "my1920x1080"
> xrandr --output DVI-0 --mode "my1920x1080"

No, monitor sees the same timins, still cannot adjust properly, and xrandr
--verbose shows the original mode as active. But I guess that could be because
it doesn't look at the name but matches on parameters?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #7 from Alex Deucher <agd5f@yahoo.com> 2012-04-18 08:38:08 PDT ---
Try switching to another mode first then switch the new one you added.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #8 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-18 08:44:56 PDT ---
(In reply to comment #7)
> Try switching to another mode first then switch the new one you added.

I did exactly that :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #9 from Alex Deucher <agd5f@yahoo.com> 2012-04-18 12:04:05 PDT ---
How is this monitor connected?  Analog VGA or digital TMDS?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #10 from Alex Deucher <agd5f@yahoo.com> 2012-04-18 12:22:55 PDT ---
Is it only problematic on VGA or TMDS?  I.e., does one only one or the other,
but not both?  It seems to be something specific to your monitor.  I can't
reproduce this on my ontario hardware or monitors.  I manually added the
modeline you were using and it works fine here.  Can you try slightly different
timing?  Some monitors are really picky about the clocks and sometimes they do
not like certain pll divider combinations even though the result is the the
same clock.  You might try setting the  RADEON_PLL_PREFER_MINM_OVER_MAXP or
RADEON_PLL_USE_FRAC_FB_DIV pll flags in atombios_adjust_pll() and see if either
of those helps.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #12 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 01:47:03 UTC ---
RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel
clock as from the modeline and locks onto it correctly.

If interesting, I collected before and after clock setup from
radeon_compute_pll_avivo. Without RADEON_PLL_PREFER_MINM_OVER_MAXP:

adjusted_clock=148500, pll_clock=14843, fb_fiv=95, frac_fb_div=0, ref_div=8,
post_div=8

With:

adjusted_clock=148500, pll_clock=14857, fb_fiv=52, frac_fb_div=0, ref_div=7,
post_div=5

Should that be the fix then or I should investigate something else?

I don't understand how without this flag monitor was claiming to be receiving
175.9MHz pixel clock. Then again pll_clock got from radeon_compute_pll_avivo
does not seem to be used later in atombios_crtc_set_pll. So perhaps driver did
attempt to set 175.9MHz pixel clock. Where would I stick some debug to know
what was definitely asked from the hardware? Because if this was true, it would
mean monitors EDID data was not being respected.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #16 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 06:45:58 UTC ---
(In reply to comment #14)
> (In reply to comment #12)
> > RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel
> > clock as from the modeline and locks onto it correctly.
> > 
> > If interesting, I collected before and after clock setup from
> > radeon_compute_pll_avivo. Without RADEON_PLL_PREFER_MINM_OVER_MAXP:
> > 
> > adjusted_clock=148500, pll_clock=14843, fb_fiv=95, frac_fb_div=0, ref_div=8,
> > post_div=8
> > 
> > With:
> > 
> > adjusted_clock=148500, pll_clock=14857, fb_fiv=52, frac_fb_div=0, ref_div=7,
> > post_div=5
> > 
> > Should that be the fix then or I should investigate something else?
> > 
> > I don't understand how without this flag monitor was claiming to be receiving
> > 175.9MHz pixel clock. Then again pll_clock got from radeon_compute_pll_avivo
> > does not seem to be used later in atombios_crtc_set_pll. So perhaps driver did
> > attempt to set 175.9MHz pixel clock. Where would I stick some debug to know
> > what was definitely asked from the hardware? Because if this was true, it would
> > mean monitors EDID data was not being respected.
> 
> As I said before some monitors are really picky about the clocks they get.  The
> pixel clock is generated from a reference clock and a set of dividers.  In some
> cases it's not possible to get exactly the pixel clock of the mode, so the
> driver gets as close as possible.  The two clocks produced are 148.43 Mhz and
> 148.57 Mhz.  Both are within 0.07 Mhz of the actual clock.  Some monitors don't
> like clocks that are slightly lower, others don't like clocks that are slightly
> higher, others don't care.  In some cases you even have monitors that don't
> like certain divider combinations that produce the exact same pixel clock.  As
> you can see from comment 11, even your own monitor is happy and not happy with
> the same pixel clock depending on the connection.

I don't take that as granted because monitor was reporting 175.9MHz in the
broken case. You haven't said anything about that observation? Do you believe
monitor is wrong there? Even though it correctly reports with other modes?

> I'd be leery of changing the pll flags without a lot of thorough testing since
> these change may break certain modes on other monitors.  Did you try
> RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
> pixel clock by allowing a finer grained fb divider, but once again, some
> monitors are picky about certain divider combinations.  I'd be more inclined to
> add this flag than the MINM_OVER_MAXP flag however.

I haven't tried RADEON_PLL_USE_FRAC_FB_DIV yet, but will now. What are the
downsides of that one? I suppose there must be some since it is not enabled by
default...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #11 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 00:51:25 PDT ---
(In reply to comment #10)
> Is it only problematic on VGA or TMDS?  I.e., does one only one or the other,
> but not both?

Just tried DVI and that works fine. Plus  monitor is displaying the expected
pixel clock, unlike over VGA.

Modeline is the same as fetched over VGA:
[61901.797355] [drm:drm_mode_debug_printmodeline], Modeline 18:"1920x1080" 60
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5

>  It seems to be something specific to your monitor.  I can't
> reproduce this on my ontario hardware or monitors.  I manually added the

Hm, we thought it may be the monitor, but, what is worrying is that monitor
thinks pixel clock is way different than what KMS is setting for 1920x1080,
while for other modes both KMS and monitor agree there.

> modeline you were using and it works fine here.  Can you try slightly different
> timing?  Some monitors are really picky about the clocks and sometimes they do
> not like certain pll divider combinations even though the result is the the
> same clock.  You might try setting the  RADEON_PLL_PREFER_MINM_OVER_MAXP or
> RADEON_PLL_USE_FRAC_FB_DIV pll flags in atombios_adjust_pll() and see if either
> of those helps.

I'll try this next.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #13 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 03:29:24 PDT ---
I've added some more debug which goes all the way to just before the ATOM BIOS
call. 

Without RADEON_PLL_PREFER_MINM_OVER_MAXP:

[    3.440262] atombios_crtc_set_pll: p1pll
[    3.440265] > atombios_adjust_pll ss_enabled=0
[    3.440267]   atombios_adjust_pll: avivo
[    3.440269]   atombios_adjust_pll: 2b
[    3.440273]   atombios_adjust_pll: AdjustDisplayPll frev=1, crev=3
[    3.440276]   atombios_adjust_pll: clock=148500
[    3.440280] - atombios_adjust_pll: adjusted_clock=148500
[    3.440285] atombios_crtc_set_pll: adjusted_clock=148500, pll_clock=14843,
fb_div=95, frac_fb_div=0, ref_div=8, post_div=8
[    3.440288] atombios_crtc_set_pll: mode->clock=148500, ss_enabled=0
[    3.440291] atombios_crtc_program_ss: DCE4
[    3.440296] atombios_crtc_program_pll: frev=1, crev=5
[    3.440301] atombios_crtc_program_pll: crtc_id=0, clock=148500, ref_div=8,
fb_div=95, frac_fb_div=0, post_div=8, bpc=8, pll_id=0, encoder_id=21,
encoder_mode=15

Monitor here claims 175.9MHz pixel clock. We have two options here. Either the
monitor is lying (for all other tested modes this monitor reports pixel clock
correctly though) or an ATOM BIOS bug?

With RADEON_PLL_PREFER_MINM_OVER_MAXP:

[    3.428121] atombios_crtc_set_pll: p1pll
[    3.428123] > atombios_adjust_pll ss_enabled=0
[    3.428125]   atombios_adjust_pll: avivo
[    3.428127]   atombios_adjust_pll: 2b
[    3.428131]   atombios_adjust_pll: AdjustDisplayPll frev=1, crev=3
[    3.428134]   atombios_adjust_pll: clock=148500
[    3.428138] - atombios_adjust_pll: adjusted_clock=148500
[    3.428143] atombios_crtc_set_pll: adjusted_clock=148500, pll_clock=14857,
fb_div=52, frac_fb_div=0, ref_div=7, post_div=5
[    3.428147] atombios_crtc_set_pll: mode->clock=148500, ss_enabled=0
[    3.428150] atombios_crtc_program_ss: DCE4
[    3.428155] atombios_crtc_program_pll: frev=1, crev=5
[    3.428160] atombios_crtc_program_pll: crtc_id=0, clock=148500, ref_div=7,
fb_div=52, frac_fb_div=0, post_div=5, bpc=8, pll_id=0, encoder_id=21,
encoder_mode=15

Monitor here correctly reports 148.5MHz pixel clock and displays the signal
fine.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #14 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 06:37:07 PDT ---
(In reply to comment #12)
> RADEON_PLL_PREFER_MINM_OVER_MAXP fixes it, monitor now reports the same pixel
> clock as from the modeline and locks onto it correctly.
> 
> If interesting, I collected before and after clock setup from
> radeon_compute_pll_avivo. Without RADEON_PLL_PREFER_MINM_OVER_MAXP:
> 
> adjusted_clock=148500, pll_clock=14843, fb_fiv=95, frac_fb_div=0, ref_div=8,
> post_div=8
> 
> With:
> 
> adjusted_clock=148500, pll_clock=14857, fb_fiv=52, frac_fb_div=0, ref_div=7,
> post_div=5
> 
> Should that be the fix then or I should investigate something else?
> 
> I don't understand how without this flag monitor was claiming to be receiving
> 175.9MHz pixel clock. Then again pll_clock got from radeon_compute_pll_avivo
> does not seem to be used later in atombios_crtc_set_pll. So perhaps driver did
> attempt to set 175.9MHz pixel clock. Where would I stick some debug to know
> what was definitely asked from the hardware? Because if this was true, it would
> mean monitors EDID data was not being respected.

As I said before some monitors are really picky about the clocks they get.  The
pixel clock is generated from a reference clock and a set of dividers.  In some
cases it's not possible to get exactly the pixel clock of the mode, so the
driver gets as close as possible.  The two clocks produced are 148.43 Mhz and
148.57 Mhz.  Both are within 0.07 Mhz of the actual clock.  Some monitors don't
like clocks that are slightly lower, others don't like clocks that are slightly
higher, others don't care.  In some cases you even have monitors that don't
like certain divider combinations that produce the exact same pixel clock.  As
you can see from comment 11, even your own monitor is happy and not happy with
the same pixel clock depending on the connection.

I'd be leery of changing the pll flags without a lot of thorough testing since
these change may break certain modes on other monitors.  Did you try
RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
pixel clock by allowing a finer grained fb divider, but once again, some
monitors are picky about certain divider combinations.  I'd be more inclined to
add this flag than the MINM_OVER_MAXP flag however.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #15 from Luc Verhaegen <libv@skynet.be> 2012-04-19 06:45:19 PDT ---
Alex, i thi(In reply to comment #14)
> 
> As I said before some monitors are really picky about the clocks they get.  The
> pixel clock is generated from a reference clock and a set of dividers.  In some
> cases it's not possible to get exactly the pixel clock of the mode, so the
> driver gets as close as possible.  The two clocks produced are 148.43 Mhz and
> 148.57 Mhz.  Both are within 0.07 Mhz of the actual clock.  Some monitors don't
> like clocks that are slightly lower, others don't like clocks that are slightly
> higher, others don't care.  In some cases you even have monitors that don't
> like certain divider combinations that produce the exact same pixel clock.  As
> you can see from comment 11, even your own monitor is happy and not happy with
> the same pixel clock depending on the connection.
> 
> I'd be leery of changing the pll flags without a lot of thorough testing since
> these change may break certain modes on other monitors.  Did you try
> RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
> pixel clock by allowing a finer grained fb divider, but once again, some
> monitors are picky about certain divider combinations.  I'd be more inclined to
> add this flag than the MINM_OVER_MAXP flag however.

Err, Alex, i think that it is the display engine, for a particular version and
process, that has issues with certain divider combinations which should
theoretically produce the same pixel clock, not the monitor.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #17 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 06:59:00 PDT ---
(In reply to comment #16)
> (In reply to comment #14)
> > I'd be leery of changing the pll flags without a lot of thorough testing since
> > these change may break certain modes on other monitors.  Did you try
> > RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
> > pixel clock by allowing a finer grained fb divider, but once again, some
> > monitors are picky about certain divider combinations.  I'd be more inclined to
> > add this flag than the MINM_OVER_MAXP flag however.
> 
> I haven't tried RADEON_PLL_USE_FRAC_FB_DIV yet, but will now. What are the
> downsides of that one? I suppose there must be some since it is not enabled by
> default...

This flag also fixes it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #18 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 07:01:10 PDT ---
(In reply to comment #15)
> 
> Err, Alex, i think that it is the display engine, for a particular version and
> process, that has issues with certain divider combinations which should
> theoretically produce the same pixel clock, not the monitor.

I'm not so sure about that.  If I use the same divider combination on my
monitors, it works fine (both TMDS and analog).  It even works fine for Tvrtko
over TMDS.  It's possible the that due to a cable problem or a bad solder
inside that the pixel clock that eventually gets to the screen is in some cases
is too low and boosting the pixel clock slightly compensates for that.


(In reply to comment #16)
> 
> I don't take that as granted because monitor was reporting 175.9MHz in the
> broken case. You haven't said anything about that observation? Do you believe
> monitor is wrong there? Even though it correctly reports with other modes?
> 

I don't know why the monitor is reporting that or how the monitor calculates
the clock it's getting.  It could be something funky with the VGA cable you are
using or a loose connection on the VGA chain somewhere.  The exact same divider
combination works fine on DVI and on other monitors.


> > I'd be leery of changing the pll flags without a lot of thorough testing since
> > these change may break certain modes on other monitors.  Did you try
> > RADEON_PLL_USE_FRAC_FB_DIV?  It should help the driver get closer to the actual
> > pixel clock by allowing a finer grained fb divider, but once again, some
> > monitors are picky about certain divider combinations.  I'd be more inclined to
> > add this flag than the MINM_OVER_MAXP flag however.
> 
> I haven't tried RADEON_PLL_USE_FRAC_FB_DIV yet, but will now. What are the
> downsides of that one? I suppose there must be some since it is not enabled by
> default...

Once again, some monitors don't like the clock produced.  It took years of fine
tuning to get a pll algo that produces good results on a wide range of
monitors.  these options may fix this mode on your monitor, but they may also
break a bunch of modes on other monitors.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #19 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 07:02:28 PDT ---
(In reply to comment #18)
> (In reply to comment #15)
> > 
> > Err, Alex, i think that it is the display engine, for a particular version and
> > process, that has issues with certain divider combinations which should
> > theoretically produce the same pixel clock, not the monitor.
> 
> I'm not so sure about that.  If I use the same divider combination on my
> monitors, it works fine (both TMDS and analog).  It even works fine for Tvrtko
> over TMDS.  It's possible the that due to a cable problem or a bad solder
> inside that the pixel clock that eventually gets to the screen is in some cases
> is too low and boosting the pixel clock slightly compensates for that.

In really it's probably a combination of both.  Some pll divider combinations
are more stable than others and some monitors are less picky.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #20 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-19 07:09:04 PDT ---
What about the BIOS bug angle? Because kernel is not setting up the hardware
directly, but asking the BIOS to do it, right? Is that out of the question?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #21 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 07:20:44 PDT ---
(In reply to comment #20)
> What about the BIOS bug angle? Because kernel is not setting up the hardware
> directly, but asking the BIOS to do it, right? Is that out of the question?

It's not out of the question, but I highly doubt it.  The driver calculates the
pll dividers and the atom table basically writes them to the pll registers.  If
there was a bug in the table, I'd expect it to cause problems across the board,
not just on one mode on one monitor.  We've had lots of these kind of bugs over
the course of the driver's life.  Some combinations of dividers and monitors
are just not happy.  The trick is to tweak the algo just enough to fix the
problematic monitor while not breaking others.  I'll test
RADEON_PLL_USE_FRAC_FB_DIV on the hw I have here and if all goes well, I'll
send it to Dave.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #22 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 07:47:09 PDT ---
Created attachment 60315
  --> https://bugs.freedesktop.org/attachment.cgi?id=60315
possible fix

use fract fb div on APUs.  Tested on all the hw I have available.  Does this
patch help with bug 48772 as well?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #23 from Luc Verhaegen <libv@skynet.be> 2012-04-19 08:15:14 PDT ---
(In reply to comment #21)
> (In reply to comment #20)
> > What about the BIOS bug angle? Because kernel is not setting up the hardware
> > directly, but asking the BIOS to do it, right? Is that out of the question?
> 
> It's not out of the question, but I highly doubt it.  The driver calculates the
> pll dividers and the atom table basically writes them to the pll registers.  If
> there was a bug in the table, I'd expect it to cause problems across the board,
> not just on one mode on one monitor.  We've had lots of these kind of bugs over
> the course of the driver's life.  Some combinations of dividers and monitors
> are just not happy.  The trick is to tweak the algo just enough to fix the
> problematic monitor while not breaking others.  I'll test
> RADEON_PLL_USE_FRAC_FB_DIV on the hw I have here and if all goes well, I'll
> send it to Dave.

The trick is testing a given version of the chip to the death and finding the
frequency limits of the inner loop of the pll. I have always managed to fully
clamp down pll ranges with a halfway decent CRT. It does take time and a
structured approach though.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #24 from Alex Deucher <agd5f@yahoo.com> 2012-04-19 08:20:03 PDT ---
(In reply to comment #23)
> 
> The trick is testing a given version of the chip to the death and finding the
> frequency limits of the inner loop of the pll. I have always managed to fully
> clamp down pll ranges with a halfway decent CRT. It does take time and a
> structured approach though.

Even then you still hit problematic monitors.  CRTs are usually pretty
forgiving; it's usually digital monitors that have problems.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #25 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-20 03:01:35 PDT ---
(In reply to comment #22)
> Created attachment 60315 [details] [review]
> possible fix
> 
> use fract fb div on APUs.  Tested on all the hw I have available.  Does this
> patch help with bug 48772 as well?

Doesn't seem to do anything for 48772.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #26 from Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> 2012-04-20 03:45:09 PDT ---
Other than that we are testing your patch on a wider range of monitors/displays
and if that goes well will take it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

Florian Mickler <florian@mickler.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |florian@mickler.org

--- Comment #27 from Florian Mickler <florian@mickler.org> 2012-04-30 02:53:36 PDT ---
A patch referencing this bug report has been merged in Linux v3.4-rc5:

commit 37d4174d2d252c37dcb3d88cafae488542087848
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Apr 19 10:48:38 2012 -0400

    drm/radeon/kms: use frac fb div on APUs

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 48880] Set mode has different timings than requested on VGA

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=48880

Alex Deucher <agd5f@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.