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