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: Fri, 28 Mar 2014 14:42:12 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1806631899==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 08D1B6ED2A for ; Fri, 28 Mar 2014 07:42:12 -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 --===============1806631899== Content-Type: multipart/alternative; boundary="1396017731.C3C87321.28745"; charset="us-ascii" --1396017731.C3C87321.28745 Date: Fri, 28 Mar 2014 14:42:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D76564 --- Comment #24 from Christian K=C3=B6nig --- (In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > >=20=20 > > > When I look at the xrandr output I wonder if the reference frequency = is not > > > 75MHz for fgrlx? Can the reference even change is this not fixed by t= he > > > hardware? > >=20 > > As far as I know, it's fixed. I'm not really sure what fglrx is doing.= =20 > > Anyway, it's probably easier to just fix the open source driver. > >=20 > > the modes are: > > 1920x1080 (0x55) 148.5MHz +HSync +VSync *current +preferred > > h: width 1920 start 2448 end 2492 total 2640 skew 0 clock= =20=20 > > 56.2KHz > > v: height 1080 start 1084 end 1089 total 1125 clock= =20=20 > > 50.0Hz > >=20 > > 1920x1080 (0x5a) 74.2MHz +HSync +VSync > > h: width 1920 start 2558 end 2602 total 2750 skew 0 clock= =20=20 > > 27.0KHz > > v: height 1080 start 1084 end 1089 total 1125 clock= =20=20 > > 24.0Hz > >=20 > > and the driver ends up calculating the dividers as such: > >=20 > > for 148.5MHz target clock: > > (100Mhz * 23.8) / (2 * 8) =3D 148.75Mhz > >=20 > > for 74.2MHz target clock: > > (100Mhz * 23.7) / (2 * 16) =3D 74.0625Mhz > >=20 > > One would need to tweak radeon_compute_pll_avivo() in radeon_display.c = to > > try and get dividers that are closer to the target clock. >=20 > Isn't that what the OSS driver is currently doing? If you look in the post > history those are the exact values that are currently being used The problem is that the frequencys are exact enough so that the display dev= ice (Monitor/TV/Whatever) accepts them, but not 100% precise. E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead. So as Alex said somebody would need to dig into that and try to improve the numbers without toasting the hardware. --=20 You are receiving this mail because: You are the assignee for the bug. --1396017731.C3C87321.28745 Date: Fri, 28 Mar 2014 14:42:11 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 24 on bug 76564<= /a> from Christian K=C3=B6nig

(In reply to comment #=
23)
> (In reply to comment #21)
> > (In reply to comment #20<=
/a>)
> > >=20=20
> > > When I look at the xrandr output I wonder if the reference f=
requency is not
> > > 75MHz for fgrlx? Can the reference even change is this not f=
ixed by the
> > > hardware?
> >=20
> > As far as I know, it's fixed.  I'm not really sure what fglrx is =
doing.=20
> > Anyway, it's probably easier to just fix the open source driver.
> >=20
> > the modes are:
> >   1920x1080 (0x55)  148.5MHz +HSync +VSync *current +preferred
> >         h: width  1920 start 2448 end 2492 total 2640 skew    0 c=
lock=20=20
> > 56.2KHz
> >         v: height 1080 start 1084 end 1089 total 1125           c=
lock=20=20
> > 50.0Hz
> >=20
> >   1920x1080 (0x5a)   74.2MHz +HSync +VSync
> >         h: width  1920 start 2558 end 2602 total 2750 skew    0 c=
lock=20=20
> > 27.0KHz
> >         v: height 1080 start 1084 end 1089 total 1125           c=
lock=20=20
> > 24.0Hz
> >=20
> > and the driver ends up calculating the dividers as such:
> >=20
> > for 148.5MHz target clock:
> > (100Mhz * 23.8) / (2 * 8) =3D 148.75Mhz
> >=20
> > for 74.2MHz target clock:
> > (100Mhz * 23.7) / (2 * 16) =3D 74.0625Mhz
> >=20
> > One would need to tweak radeon_compute_pll_avivo() in radeon_disp=
lay.c to
> > try and get dividers that are closer to the target clock.
>=20
> Isn't that what the OSS driver is currently doing? If you look in the =
post
> history those are the exact values that are currently being used

The problem is that the frequencys are exact enough so that the display dev=
ice
(Monitor/TV/Whatever) accepts them, but not 100% precise.

E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead.

So as Alex said somebody would need to dig into that and try to improve the
numbers without toasting the hardware.

You are receiving this mail because: =20=20=20=20=20=20

You are the assignee for the bug.

--1396017731.C3C87321.28745-- --===============1806631899== 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 --===============1806631899==--