From: Raphael A. <ra...@8d...> - 2006-08-14 18:39:25
Attachments:
mbxfb-disppll-workaound.diff
|
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. |
From: Antonino A. D. <ad...@gm...> - 2006-08-21 10:54:09
|
From: Raphael Assenat <ra...@8d...> 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 <ra...@8d...> Signed-off-by: Antonino Daplas <ad...@po...> --- drivers/video/mbx/mbxfb.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) 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(u /* 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) : |
From: Raphael A. <ra...@8d...> - 2006-08-15 12:45:55
|
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 |