[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Mar 31 11:09:56 PDT 2014


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

Christian König <deathsimple at vodafone.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deathsimple at vodafone.de

--- Comment #45 from Christian König <deathsimple at vodafone.de> ---
(In reply to comment #44)
> (In reply to comment #43)
> > We could also update the adjusted mode clock to the actual clock set by the
> > pll so that drm_calc_timestamping_constants() uses the actual clock value on
> > the PLL.  E.g.,
> > 
> > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> > b/drivers/gpu/drm/radeon/atombios_crtc.c
> > index daa4dd3..2a2da82 100644
> > --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> > @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc
> > *crtc, struct drm_display_mode
> >                 atombios_crtc_program_ss(rdev, ATOM_ENABLE,
> > radeon_crtc->pll_id,
> >                                          radeon_crtc->crtc_id,
> > &radeon_crtc->ss);
> >         }
> > +       mode->clock = pll_clock * 10;
> >  }
> >  
> >  static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
> 
> I think that would only help if radeon_compute_pll_avivo could not compute
> an exact match. In the case of 23.976Hz the target clock is 74170kHz and the
> PLL is set exactly to this value.
> This does raise another question why the target clock' last digit is always
> zero? For example, for 23.976Hz the target clock should be 74176kHz (with
> correct rounding). I looked through the source code, but the target clock
> seems to come all the way from some deep generic drm code.
> 
> 74176kHz could be matched by the PLL using fb=927.2, post_div=10 and
> ref_div=125

You might want to take a look at atombios_adjust_pll which does the mode fixup
before a mode is actually used.

Since atombios always works with 10khz pixel clock which always sets the target
clocks last digit to zero.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140331/edfa0382/attachment-0001.html>


More information about the dri-devel mailing list