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.