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

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.

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

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?

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"

(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?

Try switching to another mode first then switch the new one you added.

(In reply to comment #7)
> Try switching to another mode first then switch the new one you added.

I did exactly that :)

How is this monitor connected?  Analog VGA or digital TMDS?

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.

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

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.

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.

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

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.

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

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

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

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

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?

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

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?

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

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

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

Other than that we are testing your patch on a wider range of monitors/displays and if that goes well will take it.

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