[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Mar 28 08:18:18 PDT 2014
https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #25 from jeroen <jeroenk61 at hotmail.com> ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #21)
> > > (In reply to comment #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 the
> > > > hardware?
> > >
> > > As far as I know, it's fixed. I'm not really sure what fglrx is doing.
> > > Anyway, it's probably easier to just fix the open source driver.
> > >
> > > the modes are:
> > > 1920x1080 (0x55) 148.5MHz +HSync +VSync *current +preferred
> > > h: width 1920 start 2448 end 2492 total 2640 skew 0 clock
> > > 56.2KHz
> > > v: height 1080 start 1084 end 1089 total 1125 clock
> > > 50.0Hz
> > >
> > > 1920x1080 (0x5a) 74.2MHz +HSync +VSync
> > > h: width 1920 start 2558 end 2602 total 2750 skew 0 clock
> > > 27.0KHz
> > > v: height 1080 start 1084 end 1089 total 1125 clock
> > > 24.0Hz
> > >
> > > and the driver ends up calculating the dividers as such:
> > >
> > > for 148.5MHz target clock:
> > > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> > >
> > > for 74.2MHz target clock:
> > > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> > >
> > > 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.
> >
> > 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
> device (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.
So that would mean for example using fb=29.7 Ref=2 post=10?
Or would that fry the hardware?
Why must it exactly match? Because for fgrlx it seems roughly 30% higher than
needed
--
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/20140328/ab29126a/attachment.html>
More information about the dri-devel
mailing list