From: Raphael Assenat Date: Tue, 3 Oct 2006 08:15:03 +0000 (-0700) Subject: [PATCH] mbxfb: Fix a chip bug? resulting in wrong pixclock X-Git-Tag: v2.6.19-rc1~292 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=8bc218410d6c2b22a7581fac6f3dc2ac1f8fc99f;p=profile%2Fivi%2Fkernel-adaptation-intel-automotive.git [PATCH] 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. Signed-off-by: Raphael Assenat Signed-off-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c index 6849ab7..cfc6bf3 100644 --- a/drivers/video/mbx/mbxfb.c +++ b/drivers/video/mbx/mbxfb.c @@ -118,8 +118,19 @@ static unsigned int mbxfb_get_pixclock(unsigned int pixclock_ps, /* 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) :