https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #14 from Alex Deucher <agd5f@xxxxxxxxx> 2012-04-19 06:37:07 PDT --- (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. -- 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