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)
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
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.
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
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?
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"
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?
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.
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 :)
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?
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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.
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
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org