From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations Date: Mon, 31 Mar 2014 20:42:37 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1521051232==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id CC8716E42B for ; Mon, 31 Mar 2014 13:42:36 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1521051232== Content-Type: multipart/alternative; boundary="1396298556.1CaDA1.20114"; charset="us-ascii" --1396298556.1CaDA1.20114 Date: Mon, 31 Mar 2014 20:42:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=76564 --- Comment #46 from jeroen --- (In reply to comment #45) > (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. atombios_adjust_pll seems to do nothing to compensate for the 10kHz pixel clock, or didn't you mean that? When I look at drm_calc_timestamping_constants(), does this mean the vblank moment is calculated by the OSS driver? What about Alex' idea in comment 43? Would tat help Christian? -- You are receiving this mail because: You are the assignee for the bug. --1396298556.1CaDA1.20114 Date: Mon, 31 Mar 2014 20:42:36 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 46 on bug 76564 from
(In reply to comment #45)
> (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.

atombios_adjust_pll seems to do nothing to compensate for the 10kHz pixel
clock, or didn't you mean that?

When I look at drm_calc_timestamping_constants(), does this mean the vblank
moment is calculated by the OSS driver?

What about Alex' idea in comment 43? Would tat help Christian?


You are receiving this mail because:
  • You are the assignee for the bug.
--1396298556.1CaDA1.20114-- --===============1521051232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1521051232==--