Re: Atyfb questions and issues

From: Jim Ramsay (jim.ramsay_at_gmail.com)
Date: 08/15/05

  • Next message: Willy TARREAU: "Re: Linux Kernel Hang or stop after uncompressing MPC8245" 
    Date:	Mon, 15 Aug 2005 14:53:58 -0600
To: Daniël Mantione <daniel@deadlock.et.tudelft.nl>

    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/
  • Next message: Willy TARREAU: "Re: Linux Kernel Hang or stop after uncompressing MPC8245"

    Relevant Pages

    • Re: [INFO] Kernel strict versioning
      ... >> some config changes are additions, ... >> if you have the same kernel version on identical machines, ... > manually on each machine, apply the patch, recompile the modules... ...
      (Linux-Kernel)
    • Re: CONFIG_PREEMPT causes corruption of applications FPU stack
      ... acc207616a91a413a50fdd8847a747c4a7324167, i386: add sleazy FPU ... At the next context switch to process 'A' again, kernel tries to restore ... If it fixes your issue aswell, then I will re-post the patch ... During this time there were no faults on both machines. ...
      (Linux-Kernel)
    • Re: thoughts on kernel security issues
      ... but note one thing: not everybody runs vendor kernels (for various ... A person managing a park of machines ... have a buggy kernel and 100 machines to upgrade while the exploit and the ... archived mail message or a webpage with the patch. ...
      (Linux-Kernel)
    • Re: XP Home and local area network
      ... and am having some difficulty deciding what the purpose of the patch is. ... I could not help but think the problem ultimately came about when 2 machines ... and a fair amount of training in Microsoft OS ...
      (microsoft.public.windowsxp.network_web)
    • Re: [RFC][PATCH] New message-logging API (kprint)
      ... posted to the LKML and described in Documentation/kprint.txt (see patch). ... The main purpose of this change is provide a unified logging API to the ... I started this thread by posting an idea I had for shrinking the kernel by ...
      (Linux-Kernel)
    Loading