Re: Atyfb questions and issues

[Jim Ramsay]

Sorry, Daniël, forgot to CC everyone else on this - please forgive my
resend to you.

On 8/15/05, Daniël Mantione <daniel@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/