All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 48880] Set mode has different timings than requested on VGA
Date: Thu, 19 Apr 2012 13:37:07 +0000	[thread overview]
Message-ID: <bug-48880-502-kdjQEsOy16@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-48880-502@http.bugs.freedesktop.org/>

https://bugs.freedesktop.org/show_bug.cgi?id=48880

--- Comment #14 from Alex Deucher <agd5f@yahoo.com> 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.

  parent reply	other threads:[~2012-04-19 13:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 14:57 [Bug 48880] New: Set mode has different timings than requested on VGA bugzilla-daemon
2012-04-18 15:07 ` [Bug 48880] " bugzilla-daemon
2012-04-18 15:08 ` bugzilla-daemon
2012-04-18 15:18 ` bugzilla-daemon
2012-04-18 15:25 ` bugzilla-daemon
2012-04-18 15:25 ` bugzilla-daemon
2012-04-18 15:34 ` bugzilla-daemon
2012-04-18 15:38 ` bugzilla-daemon
2012-04-18 15:44 ` bugzilla-daemon
2012-04-18 19:04 ` bugzilla-daemon
2012-04-18 19:22 ` bugzilla-daemon
2012-04-19  1:47 ` bugzilla-daemon
2012-04-19  6:45 ` bugzilla-daemon
2012-04-19  7:51 ` bugzilla-daemon
2012-04-19 10:29 ` bugzilla-daemon
2012-04-19 13:37 ` bugzilla-daemon [this message]
2012-04-19 13:45 ` bugzilla-daemon
2012-04-19 13:59 ` bugzilla-daemon
2012-04-19 14:01 ` bugzilla-daemon
2012-04-19 14:02 ` bugzilla-daemon
2012-04-19 14:09 ` bugzilla-daemon
2012-04-19 14:20 ` bugzilla-daemon
2012-04-19 14:47 ` bugzilla-daemon
2012-04-19 15:15 ` bugzilla-daemon
2012-04-19 15:20 ` bugzilla-daemon
2012-04-20 10:01 ` bugzilla-daemon
2012-04-20 10:45 ` bugzilla-daemon
2012-04-30  9:53 ` bugzilla-daemon
2012-04-30 12:44 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-48880-502-kdjQEsOy16@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.