[lkml]   [2005]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-15 22:56    [W:0.031 / U:12.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site