#
c2d37953 |
|
28-Jul-2018 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|