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.