[Bug 48880] Set mode has different timings than requested on VGA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux