mbxfb: Fix a chip bug? resulting in wrong pixclock
PATCH 1/2 mbxfb: Fix a chip bug? resulting in wrong pixclock
This is a workaround for what I think is a bug in the 2700G chip.
The PLL output frequency is adustable using 3 values (M, N and P. See code for formula). The N value range is documented to be 1 to 7 but when it is set to 1, the output frequency is lower than it should be (divided by 2), giving unexpected results such as no sync on a CRT display.
This patch prevents N=1 when searching for the best value for the requested pixclock.
This is a workaround for what I think is a bug in the 2700G chip.
The PLL output frequency is adustable using 3 values (M, N and P. See code for formula). The N value range is documented to be 1 to 7 but when it is set to 1, the output frequency is lower than it should be (divided by 2), giving unexpected results such as no sync on a CRT display.
This patch prevents N=1 when searching for the best value for the requested pixclock.
drivers/video/mbx/mbxfb.c +12 -1
@@ -118,8 +118,19 @@/* convert pixclock to KHz */ pixclock =PICOS2KHZ (pixclock_ps); +/* PLL output freq = (ref_clk * M) / (N * 2^P) +* +* M: 1 to 63 +* N: 1 to 7 +* P: 0 to 7 +*/ + +/* RAPH: When N==1, the resulting pixel clock appears to +* get divided by 2. Preventing N=1 by starting the following +* loop at 2 prevents this. Is this a bug with my chip +* revision or something I dont understand? */ for (m =1 ; m <64 ; m++) { -for (n =1 ; n <8 ; n++) { +for (n =2 ; n <8 ; n++) {for (p =0 ; p <8 ; p++) { clk = (ref_clk * m) / (n * (1 << p)); err = (clk > pixclock) ? (clk - pixclock) :
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Linux-fbdev-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Quoted 7 lines · Raphael Assenat
This is a workaround for what I think is a bug in the 2700G chip.
The PLL output frequency is adustable using 3 values (M, N and P. See code for formula). The N value range is documented to be 1 to 7 but when it is set to 1, the output frequency is lower than it should be (divided by 2),
giving unexpected results such as no sync on a CRT display.
I just thought it might be useful to post information about how to reproduce this:
Install fbset and link /etc/fb.modes to the fb.modes.ATI distributed with fbset.
Do 'fbset "800x600-70" -depth 16' and the generated pixel clock will result in a v-sync around 25 hz. The 800x600-60 and 800x600-72 modes will work correctly, with the expected v-sync values.
After applying the patch, the "800x600-70" mode works correctly.
Here are the modelines from my fb.modes file, just in case:
mode "800x600-70"
# D: 44.90 MHz, H: 44.544 kHz, V: 70.04 Hz
geometry 800 600 800 600 8
timings 22272 40 24 15 9 144 12
hsync highendmode
mode "800x600-60"
# D: 40.00 MHz, H: 37.879 kHz, V: 60.32 Hz
geometry 800 600 800 600 8
timings 25000 88 40 23 1 128 4
hsync high
vsync highendmode
mode "800x600-72"
# D: 50.00 MHz, H: 48.090 kHz, V: 72.19 Hz
geometry 800 600 800 600 8
timings 20000 64 56 23 37 120 6
hsync high
vsync highendmode
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642