Commit 8bc21841 authored by Raphael Assenat's avatar Raphael Assenat Committed by Linus Torvalds

[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: default avatarRaphael Assenat <raph@8d.com>
Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent 9c5b39e0
...@@ -118,8 +118,19 @@ static unsigned int mbxfb_get_pixclock(unsigned int pixclock_ps, ...@@ -118,8 +118,19 @@ static unsigned int mbxfb_get_pixclock(unsigned int pixclock_ps,
/* convert pixclock to KHz */ /* convert pixclock to KHz */
pixclock = PICOS2KHZ(pixclock_ps); 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 (m = 1; m < 64; m++) {
for (n = 1; n < 8; n++) { for (n = 2; n < 8; n++) {
for (p = 0; p < 8; p++) { for (p = 0; p < 8; p++) {
clk = (ref_clk * m) / (n * (1 << p)); clk = (ref_clk * m) / (n * (1 << p));
err = (clk > pixclock) ? (clk - pixclock) : err = (clk > pixclock) ? (clk - pixclock) :
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment