Messages in this thread | | | Date | Mon, 15 Aug 2005 14:53:58 -0600 | From | Jim Ramsay <> | Subject | Re: Atyfb questions and issues |
| |
Sorry, Daniël, forgot to CC everyone else on this - please forgive my resend to you.
On 8/15/05, Daniël Mantione <daniel@deadlock.et.tudelft.nl> wrote: > I don't know what the purpose of this patch is but it copies the pre-LCD > version of the code in mach64_ct.c into the xlinit.c code of 2.6. This is > not the var_to_pll code. This code affects the display fifo and can > cause wrong image if incorrectly programmed, but has nothing to do with > initializing the chip.
The purpose of this patch is to get the xlinit working for non-i386 machines, such as the MIPS processor board I'm currently working with. It works for me. The problem is that for non-i386 machines, init_bios_setup is not called, so some values that the 2.6 code assumes should be initialized are not.
In the 2.4 kernel I'm using as a reference with the 'xlinit' code built in, which works on my hardware, the var_to_pll code consists of 3 calls: - aty_valid_pll_ct - aty_dsp_gt - aty_calc_pll_ct
Now, the 2.6 kernel's var_to_pll code is identical, except that it doesn't call aty_calc_pll_ct any more. However, the differences don't stop there. The 'aty_valid_pll_ct' call in the 2.6 kernel is much smaller than the 2.4 kernel - apparently it assumes that someone else will have initialized much of the pll struct.
So to work around this I took these from the 2.4 kernel, renamed them with 'init_' instead of 'aty_' and put them into xlinit.c, only if __i386__ isn't defined, and call them explicitly instead of wrapping them inside a function called 'var_to_pll'.
> The pre-LCD code caused several problems for both i386 and > non-i386 laptops, and should not be reused. Also, Geert Uytterhoeven > has said that he developed the pre-LCD by trial and and not by > design. The post-LCD code is derived from the XFree86 driver, it is > supposed to work fine if X works.
My patch won't affect non-i386 machines. Notice the '#ifndef __i386__' around everything I changed.
This simply fixes the issue that the new 2.6 xlinit code assumes that you have a bios that will do *something* to your chip before handing control over to the kernel, which is not always the case.
If you have a fix that is more correct, I'd be happy to test it for you!
-- Jim Ramsay "Me fail English? That's unpossible!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |