https://bugs.freedesktop.org/show_bug.cgi?id=48880 --- Comment #16 from Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxx> 2012-04-19 06:45:58 UTC --- (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... -- 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
