Sorry, Daniël, forgot to CC everyone else on this - please forgive my
resend to you.
On 8/15/05, Daniël Mantione <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |