linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] mbxfb: Fix a chip bug? resulting in wrong pixclock
@ 2006-08-14 18:40 Raphael Assenat
  2006-08-15 12:47 ` Raphael Assenat
  0 siblings, 1 reply; 2+ messages in thread
From: Raphael Assenat @ 2006-08-14 18:40 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: linux-fbdev-devel

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

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.


[-- Attachment #2: mbxfb-disppll-workaound.diff --]
[-- Type: text/plain, Size: 1296 bytes --]

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.

Signed-off-by: Raphael Assenat <raph@8d.com>

--- linux-2.6.18-rc2/drivers/video/mbx/mbxfb.c	2006-07-17 15:20:06.000000000 -0400
+++ linux-2.6.18-rc2-8d/drivers/video/mbx/mbxfb.c	2006-08-14 14:04:39.000000000 -0400
@@ -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) :


[-- Attachment #3: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 1/2] mbxfb: Fix a chip bug? resulting in wrong pixclock
  2006-08-14 18:40 [PATCH 1/2] mbxfb: Fix a chip bug? resulting in wrong pixclock Raphael Assenat
@ 2006-08-15 12:47 ` Raphael Assenat
  0 siblings, 0 replies; 2+ messages in thread
From: Raphael Assenat @ 2006-08-15 12:47 UTC (permalink / raw)
  To: linux-fbdev-devel

Raphael Assenat wrote:
> 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 high
endmode

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 high
endmode

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 high
endmode



-------------------------------------------------------------------------
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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-08-15 12:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-14 18:40 [PATCH 1/2] mbxfb: Fix a chip bug? resulting in wrong pixclock Raphael Assenat
2006-08-15 12:47 ` Raphael Assenat

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).