summaryrefslogtreecommitdiff
path: root/drivers/video/mbx
diff options
context:
space:
mode:
authorRaphael Assenat <raph@8d.com>2006-10-03 01:15:03 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-10-03 08:04:12 -0700
commit8bc218410d6c2b22a7581fac6f3dc2ac1f8fc99f (patch)
treee4b0ef3693052742df0233ab9c3a706382307ee3 /drivers/video/mbx
parent9c5b39e0bcb407a95716de4650a2d1e6064baffa (diff)
[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 <raph@8d.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/video/mbx')
-rw-r--r--drivers/video/mbx/mbxfb.c13
1 files changed, 12 insertions, 1 deletions
diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
index 6849ab75d403..cfc6bf3615b5 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) :