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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #27 from Christian König <deathsimple at vodafone.de> ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > (In reply to comment #23)
> > > 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?
> 
> That should work.  You aren't likely to fry the hw.  You just don't want to
> set a 400 Mhz clock as you monitor properly won't like it.  The hard part is
> adjusting the algorithm to reliably calculate a good value for a wide range
> of clocks.

I'm not sure if those values would work. A post divider of 10 might result in a
to high VCO and that could indeed damage the hardware (even if that's rather
unlikely).

Essentially the target clock multiplied with the post divider must be in a
certain range. I think between pll->pll_out_max and pll->pll_out_min.

I think the problem is that we don't try to choose a good value to match the
target frequency as close as possible in avivo_get_post_div, but just a value
that either matches the maximum or minimum VCO frequency.

-- 
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/1f5e5489/attachment.html>