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>
