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 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--
--===============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==--