https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #12 from Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxx> 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. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
