Bug 48880 - Set mode has different timings than requested on VGA
Summary: Set mode has different timings than requested on VGA
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-18 07:57 UTC by Tvrtko Ursulin
Modified: 2012-04-30 05:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
possible fix (1.05 KB, patch)
2012-04-19 07:47 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tvrtko Ursulin 2012-04-18 07:57:24 UTC
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)
Comment 1 Tvrtko Ursulin 2012-04-18 08:07:47 UTC
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
Comment 2 Tvrtko Ursulin 2012-04-18 08:08:39 UTC
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.
Comment 3 Tvrtko Ursulin 2012-04-18 08:18:54 UTC
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
Comment 4 Tvrtko Ursulin 2012-04-18 08:25:15 UTC
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?
Comment 5 Alex Deucher 2012-04-18 08:25:53 UTC
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"
Comment 6 Tvrtko Ursulin 2012-04-18 08:34:44 UTC
(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?
Comment 7 Alex Deucher 2012-04-18 08:38:08 UTC
Try switching to another mode first then switch the new one you added.
Comment 8 Tvrtko Ursulin 2012-04-18 08:44:56 UTC
(In reply to comment #7)
> Try switching to another mode first then switch the new one you added.

I did exactly that :)
Comment 9 Alex Deucher 2012-04-18 12:04:05 UTC
How is this monitor connected?  Analog VGA or digital TMDS?
Comment 10 Alex Deucher 2012-04-18 12:22:55 UTC
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.
Comment 11 Tvrtko Ursulin 2012-04-19 00:51:25 UTC
(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.
Comment 12 Tvrtko Ursulin 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.
Comment 13 Tvrtko Ursulin 2012-04-19 03:29:24 UTC
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.
Comment 14 Alex Deucher 2012-04-19 06:37:07 UTC
(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.
Comment 15 Luc Verhaegen 2012-04-19 06:45:19 UTC
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.
Comment 16 Tvrtko Ursulin 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...
Comment 17 Tvrtko Ursulin 2012-04-19 06:59:00 UTC
(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.
Comment 18 Alex Deucher 2012-04-19 07:01:10 UTC
(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.
Comment 19 Alex Deucher 2012-04-19 07:02:28 UTC
(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.
Comment 20 Tvrtko Ursulin 2012-04-19 07:09:04 UTC
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?
Comment 21 Alex Deucher 2012-04-19 07:20:44 UTC
(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.
Comment 22 Alex Deucher 2012-04-19 07:47:09 UTC
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?
Comment 23 Luc Verhaegen 2012-04-19 08:15:14 UTC
(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.
Comment 24 Alex Deucher 2012-04-19 08:20:03 UTC
(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.
Comment 25 Tvrtko Ursulin 2012-04-20 03:01:35 UTC
(In reply to comment #22)
> Created attachment 60315 [details] [review] [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.
Comment 26 Tvrtko Ursulin 2012-04-20 03:45:09 UTC
Other than that we are testing your patch on a wider range of monitors/displays and if that goes well will take it.
Comment 27 Florian Mickler 2012-04-30 02:53:36 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.