https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #28 from jeroen jeroenk61@hotmail.com --- (In reply to comment #27)
(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.
Perhaps before somebody is going to modify the algorithm, it is a good idea to verify that this is indeed the problem. If this is the problem why don't more people have these problems?
If I know which values for fb,ref and post to use for 23.976fps I can hard code these In a patch and test if it indeed works.
So which values are save to get a clock of 74.2MHz?