Atyfb questions and issues

Atyfb questions and issues

[Jim Ramsay]

I have the following issue.  I am trying to get an ATI Rage XL chip
working on a MIPS-based processor, with a 2.6.11-based kernel from
linux-mips.org.  Now, I know that this was working with a 2.4.25-based
kernel previously.

I seem to get intermittent strange issues, such as the machine
freezing from time to time, but in general I get the following in my
dmesg when I load the atyfb module:

atyfb: using auxiliary register aperture
atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27]
atyfb(aty_valid_pll_ct): pllvclk=50 MHz, vclk=25 MHz
atyfb(aty_dsp_gt): dsp_config 0x307c0001, dsp_on_off 0x14fffff0
< Sometimes it will hang here >
atyfb: 512K RESV, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
atyfb: Unsupported xclk source:  7.
< Followed by a number of >
atyfb: vclk out of range
< and >
atyfb: not enough video RAM
< Finally I get >
atyfb: can't set default video mode                                             
atyfb(aty_set_pll_ct): about to program:                                        
pll_ext_cntl=0x0f pll_gen_cntl=0xff pll_vclk_cntl=0xad                          
atyfb(aty_set_pll_ct): setting clock 3 for FeedBackDivider 255, ReferenceDivider
 255, PostDivider 3(0)
< Other times it will hang here >

And that's all I get.

I'm assuming that most of my issues are due to the "Unsupported xclk
source" message.  Any ideas what I can do about this, or where I can
go to learn more about how to make this thing work?

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

Re: Atyfb questions and issues

[Daniël Mantione]

Op Fri, 12 Aug 2005, schreef Jim Ramsay:

> I have the following issue.  I am trying to get an ATI Rage XL chip
> working on a MIPS-based processor, with a 2.6.11-based kernel from
> linux-mips.org.  Now, I know that this was working with a 2.4.25-based
> kernel previously.

Okay, the 2.4 driver is more intrusive, it programs the chip from start as
much as possible, while the 2.6 driver tries to depend on Bios settings. I
haven't checked out the 2.6 driver enough to see if it is still possible
to program from scratch.

> I seem to get intermittent strange issues, such as the machine
> freezing from time to time, but in general I get the following in my
> dmesg when I load the atyfb module:
>
> atyfb: using auxiliary register aperture
> atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27]
> atyfb(aty_valid_pll_ct): pllvclk=50 MHz, vclk=25 MHz
> atyfb(aty_dsp_gt): dsp_config 0x307c0001, dsp_on_off 0x14fffff0
> < Sometimes it will hang here >
> atyfb: 512K RESV, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
> atyfb: Unsupported xclk source:  7.

> I'm assuming that most of my issues are due to the "Unsupported xclk
> source" message.  Any ideas what I can do about this, or where I can
> go to learn more about how to make this thing work?

Yes, according to my register data sheet a 7 means the memory clock
frequency is derived from DLLCLK. Unfortunately I don't know what this
DLLCLK is. I think it means the chip isn't properly initialized yet and it
clocks the memory from a safe clock source to allow the computer to start.

However, we most likely have no way to find out the speed of this DLLCLK.

The memory clock frequency is important for the driver to be able to set a
display mode; it needs to program a memory reload frequency into the chip
which depends on the memory frequency.

Daniël

Re: Atyfb questions and issues

[James Simmons]

> > I have the following issue.  I am trying to get an ATI Rage XL chip
> > working on a MIPS-based processor, with a 2.6.11-based kernel from
> > linux-mips.org.  Now, I know that this was working with a 2.4.25-based
> > kernel previously.
> 
> Okay, the 2.4 driver is more intrusive, it programs the chip from start as
> much as possible, while the 2.6 driver tries to depend on Bios settings. I
> haven't checked out the 2.6 driver enough to see if it is still possible
> to program from scratch.

The code is there to program the chip from scratch. Just select 

"Rage XL No-BIOS Init support"

The last time I tried it it didn't work. If we could get it working that 
would be great.
 
> Yes, according to my register data sheet a 7 means the memory clock
> frequency is derived from DLLCLK. Unfortunately I don't know what this
> DLLCLK is. I think it means the chip isn't properly initialized yet and it
> clocks the memory from a safe clock source to allow the computer to start.
> 
> However, we most likely have no way to find out the speed of this DLLCLK.
> 
> The memory clock frequency is important for the driver to be able to set a
> display mode; it needs to program a memory reload frequency into the chip
> which depends on the memory frequency.

Their is code in xlint.c that should properly set this. Have to debug that 
code.

Re: Atyfb questions and issues

[yhlu]

james,

I remember that xlinit in 2.6 kernel only works when BIOS option-rom
really init fb.
It can not work if the BIOS option rom is not executed.

For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
Only work if BIOS don't excute the option rom.

YH

On 8/12/05, James Simmons <jsimmons@infradead.org> wrote:
> 
> > > I have the following issue.  I am trying to get an ATI Rage XL chip
> > > working on a MIPS-based processor, with a 2.6.11-based kernel from
> > > linux-mips.org.  Now, I know that this was working with a 2.4.25-based
> > > kernel previously.
> >
> > Okay, the 2.4 driver is more intrusive, it programs the chip from start as
> > much as possible, while the 2.6 driver tries to depend on Bios settings. I
> > haven't checked out the 2.6 driver enough to see if it is still possible
> > to program from scratch.
> 
> The code is there to program the chip from scratch. Just select
> 
> "Rage XL No-BIOS Init support"
> 
> The last time I tried it it didn't work. If we could get it working that
> would be great.
> 
> > Yes, according to my register data sheet a 7 means the memory clock
> > frequency is derived from DLLCLK. Unfortunately I don't know what this
> > DLLCLK is. I think it means the chip isn't properly initialized yet and it
> > clocks the memory from a safe clock source to allow the computer to start.
> >
> > However, we most likely have no way to find out the speed of this DLLCLK.
> >
> > The memory clock frequency is important for the driver to be able to set a
> > display mode; it needs to program a memory reload frequency into the chip
> > which depends on the memory frequency.
> 
> Their is code in xlint.c that should properly set this. Have to debug that
> code.
> 
> -
> 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/
>

Re: Atyfb questions and issues

[James Simmons]

> james,
> 
> I remember that xlinit in 2.6 kernel only works when BIOS option-rom
> really init fb.
> It can not work if the BIOS option rom is not executed.
> 
> For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
> Only work if BIOS don't excute the option rom.

You are right. The init_from_bios is called on x86 in aty_setup_generic 
before aty_init which calls the biosless initialization. The question is 
what needs to be done to properly fix it?

Re: Atyfb questions and issues

[yhlu]

last year some time, I have manually the patch from 2.4 to 2.6. my
patch result is the same as 2.4. It only works when bios doesn't do
the init. Then if the BIOS do the init, it will hang there. I assume
something only can be done once.

YH

On 8/15/05, James Simmons <jsimmons@infradead.org> wrote:
> 
> > james,
> >
> > I remember that xlinit in 2.6 kernel only works when BIOS option-rom
> > really init fb.
> > It can not work if the BIOS option rom is not executed.
> >
> > For 2.4, it reversed, it can not work if BIOS opton-rom is executed.
> > Only work if BIOS don't excute the option rom.
> 
> You are right. The init_from_bios is called on x86 in aty_setup_generic
> before aty_init which calls the biosless initialization. The question is
> what needs to be done to properly fix it?
> 
>

Re: Atyfb questions and issues

[Jim Ramsay]

On 8/15/05, yhlu <yhlu.kernel@gmail.com> wrote:
> last year some time, I have manually the patch from 2.4 to 2.6. my
> patch result is the same as 2.4. It only works when bios doesn't do
> the init. Then if the BIOS do the init, it will hang there. I assume
> something only can be done once.

That is exactly what I did in my proposed patch, attached earlier.

I noticed the same problem.

Does anyone out there know how you can tell if the RageXL chip has
already been initialized?

One test I have that works on my hardware is to test the STAT0
register.  If it ends with 0x95, the chip has not been initialized,
otherwise I initialize it.

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

Re: Atyfb questions and issues

[Daniël Mantione]

Op Mon, 15 Aug 2005, schreef Jim Ramsay:

> On 8/15/05, yhlu <yhlu.kernel@gmail.com> wrote:
> > last year some time, I have manually the patch from 2.4 to 2.6. my
> > patch result is the same as 2.4. It only works when bios doesn't do
> > the init. Then if the BIOS do the init, it will hang there. I assume
> > something only can be done once.
>
> That is exactly what I did in my proposed patch, attached earlier.
>
> I noticed the same problem.
>
> Does anyone out there know how you can tell if the RageXL chip has
> already been initialized?
>
> One test I have that works on my hardware is to test the STAT0
> register.  If it ends with 0x95, the chip has not been initialized,
> otherwise I initialize it.

Perhaps you can check if the oscillators are enabled. If the chip is being
clocked for DLLCLK and that kind of clocks, the internal clock synthesizer
is most likely not yet programmed to generate usefull clock signals and I
would expect its oscillator to be switched off.

Daniël

Re: Atyfb questions and issues

[yhlu]

I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS.

there is one patch call xlinit.c that can be used even ati fb is not
inited in BIOS to make kernel still can use atyfb.

I wonder if James put that in mainstream, he already sent one patch
for 2.6.5....

please refer to 
http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html

I guess the mips fw already execute the ati option rom via x86 emulator...

YH

On 8/12/05, Daniël Mantione <daniel@deadlock.et.tudelft.nl> wrote:
> 
> 
> Op Fri, 12 Aug 2005, schreef Jim Ramsay:
> 
> > I have the following issue.  I am trying to get an ATI Rage XL chip
> > working on a MIPS-based processor, with a 2.6.11-based kernel from
> > linux-mips.org.  Now, I know that this was working with a 2.4.25-based
> > kernel previously.
> 
> Okay, the 2.4 driver is more intrusive, it programs the chip from start as
> much as possible, while the 2.6 driver tries to depend on Bios settings. I
> haven't checked out the 2.6 driver enough to see if it is still possible
> to program from scratch.
> 
> > I seem to get intermittent strange issues, such as the machine
> > freezing from time to time, but in general I get the following in my
> > dmesg when I load the atyfb module:
> >
> > atyfb: using auxiliary register aperture
> > atyfb: 3D RAGE XL (Mach64 GR, PCI-33MHz) [0x4752 rev 0x27]
> > atyfb(aty_valid_pll_ct): pllvclk=50 MHz, vclk=25 MHz
> > atyfb(aty_dsp_gt): dsp_config 0x307c0001, dsp_on_off 0x14fffff0
> > < Sometimes it will hang here >
> > atyfb: 512K RESV, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
> > atyfb: Unsupported xclk source:  7.
> 
> > I'm assuming that most of my issues are due to the "Unsupported xclk
> > source" message.  Any ideas what I can do about this, or where I can
> > go to learn more about how to make this thing work?
> 
> Yes, according to my register data sheet a 7 means the memory clock
> frequency is derived from DLLCLK. Unfortunately I don't know what this
> DLLCLK is. I think it means the chip isn't properly initialized yet and it
> clocks the memory from a safe clock source to allow the computer to start.
> 
> However, we most likely have no way to find out the speed of this DLLCLK.
> 
> The memory clock frequency is important for the driver to be able to set a
> display mode; it needs to program a memory reload frequency into the chip
> which depends on the memory frequency.
> 
> Daniël
> 
> -
> 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/
>

Re: Atyfb questions and issues

[Jim Ramsay]

On 8/12/05, yhlu <yhlu.kernel@gmail.com> wrote:
> I played a while with atyfb in LinuxBIOS. move the xl_init.c into LinuxBIOS.
> 
> there is one patch call xlinit.c that can be used even ati fb is not
> inited in BIOS to make kernel still can use atyfb.
> 
> I wonder if James put that in mainstream, he already sent one patch
> for 2.6.5....
> 
> please refer to
> http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html

It appears to me that this patch is in the 2.6.11 from linux-mips.org
that I am presently using.

> I guess the mips fw already execute the ati option rom via x86 emulator...

Maybe his mips FW does this, but mine doesn't.  Any tips on how I can
do this in software?

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

Re: Atyfb questions and issues

[James Simmons]

> > I wonder if James put that in mainstream, he already sent one patch
> > for 2.6.5....
> > 
> > please refer to
> > http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html
> 
> It appears to me that this patch is in the 2.6.11 from linux-mips.org
> that I am presently using.

Its in the standard tree as well. The question is does it work in the mips 
branch? Last time I tried booting without the bios it did not work. Yhlu 
is right, atyfb_setup_generic is called which in x86 calls the 
init_from_bios function. Then in aty_init is the biosless initializing is 
done. 

> Maybe his mips FW does this, but mine doesn't.  Any tips on how I can
> do this in software?

The idea of the patch is not to need FW.

Re: Atyfb questions and issues

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On 8/15/05, James Simmons <jsimmons@infradead.org> wrote:
> 
> > > I wonder if James put that in mainstream, he already sent one patch
> > > for 2.6.5....
> > >
> > > please refer to
> > > http://www.linuxbios.org/pipermail/linuxbios/2004-May/007734.html
> >
> > It appears to me that this patch is in the 2.6.11 from linux-mips.org
> > that I am presently using.
> 
> Its in the standard tree as well. The question is does it work in the mips
> branch? Last time I tried booting without the bios it did not work. Yhlu
> is right, atyfb_setup_generic is called which in x86 calls the
> init_from_bios function. Then in aty_init is the biosless initializing is
> done.
> 
> > Maybe his mips FW does this, but mine doesn't.  Any tips on how I can
> > do this in software?
> 
> The idea of the patch is not to need FW.

Of course.

How about the replacement for 'xlinit.c' I have attached here?

I noticed that the big difference between what the 2.4 kernel and 2.6
kernel did is that the 'var_to_pll' (and its component functions) in
2.4 did a lot more probing than that in the 2.6 kernel.

So I copied the relevant 2.4 bits for non-i386 archs, and replaced the
call to 'var_to_pll' with the "new" stuff.

This seems to work for me.  Enjoy!

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xlinit.c --]
[-- Type: text/x-csrc; name="xlinit.c", Size: 17864 bytes --]

/*
 *  ATI Rage XL Initialization. Support for Xpert98 and Victoria
 *  PCI cards.
 *
 *  Copyright (C) 2002 MontaVista Software Inc.
 *  Author: MontaVista Software, Inc.
 *         	stevel@mvista.com or source@mvista.com
 *
 *  This program is free software; you can redistribute  it and/or modify it
 *  under  the terms of  the GNU General  Public License as published by the
 *  Free Software Foundation;  either version 2 of the  License, or (at your
 *  option) any later version.
 *
 *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
 *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
 *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
 *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
 *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
 *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
 *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 *  You should have received a copy of the  GNU General Public License along
 *  with this program; if not, write  to the Free Software Foundation, Inc.,
 *  675 Mass Ave, Cambridge, MA 02139, USA.
 */
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h> 
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/pci.h>
#include <asm/io.h>
#include <video/mach64.h>
#include "atyfb.h"

#define MPLL_GAIN       0xad
#define VPLL_GAIN       0xd5

enum {
	VICTORIA = 0,
	XPERT98,
	NUM_XL_CARDS
};

extern const struct aty_pll_ops aty_pll_ct;

#define DEFAULT_CARD XPERT98
static int xl_card = DEFAULT_CARD;

static const struct xl_card_cfg_t {
	int ref_crystal; // 10^4 Hz
	int mem_type;
	int mem_size;
	u32 mem_cntl;
	u32 ext_mem_cntl;
	u32 mem_addr_config;
	u32 bus_cntl;
	u32 dac_cntl;
	u32 hw_debug;
	u32 custom_macro_cntl;
	u8  dll2_cntl;
	u8  pll_yclk_cntl;
} card_cfg[NUM_XL_CARDS] = {
	// VICTORIA
	{	2700, SDRAM, 0x800000,
		0x10757A3B, 0x64000C81, 0x00110202, 0x7b33A040,
		0x82010102, 0x48803800, 0x005E0179,
		0x50, 0x25
	},
	// XPERT98
	{	1432,  WRAM, 0x800000,
		0x00165A2B, 0xE0000CF1, 0x00200213, 0x7333A001,
		0x8000000A, 0x48833800, 0x007F0779,
		0x10, 0x19
	}
};
	  
typedef struct {
	u8 lcd_reg;
	u32 val;
} lcd_tbl_t;

static const lcd_tbl_t lcd_tbl[] = {
	{ 0x01,	0x000520C0 },
	{ 0x08,	0x02000408 },
	{ 0x03,	0x00000F00 },
	{ 0x00,	0x00000000 },
	{ 0x02,	0x00000000 },
	{ 0x04,	0x00000000 },
	{ 0x05,	0x00000000 },
	{ 0x06,	0x00000000 },
	{ 0x33,	0x00000000 },
	{ 0x34,	0x00000000 },
	{ 0x35,	0x00000000 },
	{ 0x36,	0x00000000 },
	{ 0x37,	0x00000000 }
};

static void reset_gui(struct atyfb_par *par)
{
	aty_st_8(GEN_TEST_CNTL+1, 0x01, par);
	aty_st_8(GEN_TEST_CNTL+1, 0x00, par);
	aty_st_8(GEN_TEST_CNTL+1, 0x02, par);
	mdelay(5);
}

static void reset_sdram(struct atyfb_par *par)
{
	u8 temp;

	temp = aty_ld_8(EXT_MEM_CNTL, par);
	temp |= 0x02;
	aty_st_8(EXT_MEM_CNTL, temp, par); // MEM_SDRAM_RESET = 1b
	temp |= 0x08;
	aty_st_8(EXT_MEM_CNTL, temp, par); // MEM_CYC_TEST    = 10b
	temp |= 0x0c;
	aty_st_8(EXT_MEM_CNTL, temp, par); // MEM_CYC_TEST    = 11b
	mdelay(5);
	temp &= 0xf3;
	aty_st_8(EXT_MEM_CNTL, temp, par); // MEM_CYC_TEST    = 00b
	temp &= 0xfd;
	aty_st_8(EXT_MEM_CNTL, temp, par); // MEM_SDRAM_REST  = 0b
	mdelay(5);
}

static void init_dll(struct atyfb_par *par)
{
	// enable DLL
	aty_st_pll_ct(PLL_GEN_CNTL,
		   aty_ld_pll_ct(PLL_GEN_CNTL, par) & 0x7f,
		   par);

	// reset DLL
	aty_st_pll_ct(DLL_CNTL, 0x82, par);
	aty_st_pll_ct(DLL_CNTL, 0xE2, par);
	mdelay(5);
	aty_st_pll_ct(DLL_CNTL, 0x82, par);
	mdelay(6);
}

static void reset_clocks(struct atyfb_par *par, struct pll_ct *pll,
			 int hsync_enb)
{
	reset_gui(par);
	aty_st_pll_ct(MCLK_FB_DIV, pll->mclk_fb_div, par);
	aty_st_pll_ct(SCLK_FB_DIV, pll->sclk_fb_div, par);

	mdelay(15);
	init_dll(par);
	aty_st_8(GEN_TEST_CNTL+1, 0x00, par);
	mdelay(5);
	aty_st_8(CRTC_GEN_CNTL+3, 0x04, par);
	mdelay(6);
	reset_sdram(par);
	aty_st_8(CRTC_GEN_CNTL+3,
		 hsync_enb ? 0x00 : 0x04, par);

	aty_st_pll_ct(SPLL_CNTL2, pll->spll_cntl2, par);
	aty_st_pll_ct(PLL_GEN_CNTL, pll->pll_gen_cntl, par);
	aty_st_pll_ct(PLL_VCLK_CNTL, pll->pll_vclk_cntl, par);
}

#ifndef __i386__
/*
 * These 3 routines (init_valid_pll_ct, init_dsp_gt, init_calc_pll_ct)
 * are copied from the 2.4 initialization which properly initializes a
 * bios-less chip.
 *
 * The i386 version includes code which uses the bios init instead, so
 * these are unnecessary there.
 */

#define FAIL(x) do { printk(x "\n"); return -EINVAL; } while (0)

static int init_valid_pll_ct(const struct fb_info *info, u32 vclk_per,
                            struct pll_ct *pll)
{
#ifdef DEBUG
    int pllmclk, pllsclk;
#endif
    u32 q;
    struct atyfb_par *par = (struct atyfb_par *) info->par;

    pll->pll_ref_div = par->pll_per * 2 * 255 / par->ref_clk_per;

    /* FIXME: use the VTB/GTB /3 post divider if it's better suited */

    /* actually 8*q */
    q = par->ref_clk_per*pll->pll_ref_div*4/par->mclk_per;

    if (q < 16*8 || q > 255*8)
        FAIL("mclk out of range");
    else if (q < 32*8)
        pll->mclk_post_div_real = 8;
    else if (q < 64*8)
        pll->mclk_post_div_real = 4;
    else if (q < 128*8)
        pll->mclk_post_div_real = 2;
    else
        pll->mclk_post_div_real = 1;
    pll->sclk_fb_div = q*pll->mclk_post_div_real/8;

#ifdef DEBUG
    pllsclk = (1000000 * 2 * pll->sclk_fb_div) /
            (par->ref_clk_per * pll->pll_ref_div);
    printk(__FUNCTION__ ": pllsclk=%d MHz, mclk=%d MHz\n",
           pllsclk, pllsclk / pll->mclk_post_div_real);
#endif

    pll->mclk_fb_mult = M64_HAS(MFB_FORCE_4) ? 4 : 2;

    /* actually 8*q */
    q = par->ref_clk_per * pll->pll_ref_div * 8 /
            (pll->mclk_fb_mult * par->xclk_per);

    if (q < 16*8 || q > 255*8)
        FAIL("mclk out of range");
    else if (q < 32*8)
        pll->xclk_post_div_real = 8;
    else if (q < 64*8)
        pll->xclk_post_div_real = 4;
    else if (q < 128*8)
        pll->xclk_post_div_real = 2;
    else
        pll->xclk_post_div_real = 1;
    pll->mclk_fb_div = q*pll->xclk_post_div_real/8;

#ifdef DEBUG
    pllmclk = (1000000 * pll->mclk_fb_mult * pll->mclk_fb_div) /
            (par->ref_clk_per * pll->pll_ref_div);
    printk(__FUNCTION__ ": pllmclk=%d MHz, xclk=%d MHz\n",
           pllmclk, pllmclk / pll->xclk_post_div_real);
#endif

    /* FIXME: use the VTB/GTB /{3,6,12} post dividers if they're better suited */
    q = par->ref_clk_per*pll->pll_ref_div*4/vclk_per;  /* actually 8*q */
    if (q < 16*8 || q > 255*8)
        FAIL("vclk out of range");
    else if (q < 32*8)
        pll->vclk_post_div_real = 8;
    else if (q < 64*8)
        pll->vclk_post_div_real = 4;
    else if (q < 128*8)
        pll->vclk_post_div_real = 2;
    else
        pll->vclk_post_div_real = 1;
    pll->vclk_fb_div = q*pll->vclk_post_div_real/8;
    return 0;
}

static int init_dsp_gt(const struct fb_info *info, u32 bpp,
                      struct pll_ct *pll)
{
    struct atyfb_par *par = (struct atyfb_par *) info->par;
    u32 dsp_xclks_per_row, dsp_loop_latency, dsp_precision, dsp_off, dsp_on;
    u32 xclks_per_row, fifo_off, fifo_on, y, fifo_size;
    u32 memcntl, n, t_pfc, t_rp, t_ras, t_rcd, t_crd, t_rcc, t_lat;

#ifdef DEBUG
    printk(__FUNCTION__ ": mclk_fb_mult=%d\n", pll->mclk_fb_mult);
#endif

    /* (64*xclk/vclk/bpp)<<11 = xclocks_per_row<<11 */
    xclks_per_row = ((u32)pll->mclk_fb_mult * (u32)pll->mclk_fb_div *
                     (u32)pll->vclk_post_div_real * 64) << 11;
    xclks_per_row /=
            (2 * (u32)pll->vclk_fb_div * (u32)pll->xclk_post_div_real * bpp);

    if (xclks_per_row < (1<<11))
        FAIL("Dotclock too high");
    if (M64_HAS(FIFO_32)) {
        fifo_size = 32;
        dsp_loop_latency = 2;
    } else {
        fifo_size = 24;
        dsp_loop_latency = 0;
    }
    dsp_precision = 0;
    y = (xclks_per_row*fifo_size)>>11;
    while (y) {
        y >>= 1;
        dsp_precision++;
    }
    dsp_precision -= 5;

    /* fifo_off<<6 */
    fifo_off = ((xclks_per_row*(fifo_size-1))>>5); // + (3<<6);

    if (info->fix.smem_len > 1*1024*1024) {
        switch (par->ram_type) {
        case WRAM:
            /* >1 MB WRAM */
            dsp_loop_latency += 9;
            n = 4;
            break;
        case SDRAM:
        case SGRAM:
            /* >1 MB SDRAM */
            dsp_loop_latency += 8;
            n = 2;
            break;
        default:
            /* >1 MB DRAM */
            dsp_loop_latency += 6;
            n = 3;
            break;
        }
    } else {
        if (par->ram_type >= SDRAM) {
            /* <2 MB SDRAM */
            dsp_loop_latency += 9;
            n = 2;
        } else {
            /* <2 MB DRAM */
            dsp_loop_latency += 8;
            n = 3;
        }
    }

    memcntl = aty_ld_le32(MEM_CNTL, par);
    t_rcd = ((memcntl >> 10) & 0x03) + 1;
    t_crd = ((memcntl >> 12) & 0x01);
    t_rp  = ((memcntl >>  8) & 0x03) + 1;
    t_ras = ((memcntl >> 16) & 0x07) + 1;
    t_lat =  (memcntl >>  4) & 0x03;

    t_pfc = t_rp + t_rcd + t_crd;

    t_rcc = max(t_rp + t_ras, t_pfc + n);

    /* fifo_on<<6 */
    fifo_on = (2 * t_rcc + t_pfc + n - 1) << 6;

    dsp_xclks_per_row = xclks_per_row>>dsp_precision;
    dsp_on = fifo_on>>dsp_precision;
    dsp_off = fifo_off>>dsp_precision;

    pll->dsp_config = (dsp_xclks_per_row & 0x3fff) |
                      ((dsp_loop_latency & 0xf)<<16) |
                      ((dsp_precision & 7)<<20);
    pll->dsp_on_off = (dsp_off & 0x7ff) | ((dsp_on & 0x7ff)<<16);
    return 0;
}

void init_calc_pll_ct(const struct fb_info *info, struct pll_ct *pll)
{
    struct atyfb_par *par = (struct atyfb_par *) info->par;
    u8 xpostdiv = 0;
    u8 mpostdiv = 0;  
    u8 vpostdiv = 0;  
    
    if (M64_HAS(SDRAM_MAGIC_PLL) && (par->ram_type >= SDRAM))
            pll->pll_gen_cntl = 0x64; /* mclk = sclk */
    else
        pll->pll_gen_cntl = 0xe4; /* mclk = sclk */

    switch (pll->mclk_post_div_real) {
        case 1:
            mpostdiv = 0;
            break;
        case 2:
            mpostdiv = 1;
            break;
        case 4:
            mpostdiv = 2;
            break;
        case 8:
            mpostdiv = 3;
            break;
    }       
    
    pll->spll_cntl2 = mpostdiv << 4; /* sclk == pllsclk / mpostdiv */
    
    switch (pll->xclk_post_div_real) {
        case 1:
            xpostdiv = 0;
            break;
        case 2:
            xpostdiv = 1;
            break;
        case 3:
            xpostdiv = 4;
            break;
        case 4:
            xpostdiv = 2;
            break;
        case 8:
            xpostdiv = 3;
            break;
    }

    if (M64_HAS(MAGIC_POSTDIV))
        pll->pll_ext_cntl = 0;
    else
        pll->pll_ext_cntl = xpostdiv;   /* xclk == pllmclk / xpostdiv */

    if (pll->mclk_fb_mult == 4)
            pll->pll_ext_cntl |= 0x08;

    switch (pll->vclk_post_div_real) {
        case 2:
            vpostdiv = 1;
            break;
        case 3:
            pll->pll_ext_cntl |= 0x10;
        case 1:
            vpostdiv = 0;
            break;
        case 6:
            pll->pll_ext_cntl |= 0x10;
        case 4:
            vpostdiv = 2;
            break;
        case 12:
            pll->pll_ext_cntl |= 0x10;
        case 8:
            vpostdiv = 3;
            break;
    }

    pll->pll_vclk_cntl = 0x03;  /* VCLK = PLL_VCLK/VCLKx_POST */
    pll->vclk_post_div = vpostdiv;
}
#endif // __i386__

int atyfb_xl_init(struct fb_info *info)
{
	const struct xl_card_cfg_t * card = &card_cfg[xl_card];
	struct atyfb_par *par = (struct atyfb_par *) info->par;
	union aty_pll pll;
	int err;
	u32 temp;

	aty_st_8(CONFIG_STAT0, 0x85, par);
	mdelay(10);

	/*
	 * The following needs to be set before the call
	 * to var_to_pll() below. They'll be re-set again
	 * to the same values in aty_init().
	 */
	par->ref_clk_per = 100000000UL/card->ref_crystal;
	par->ram_type = card->mem_type;
	info->fix.smem_len = card->mem_size;
	if (xl_card == VICTORIA) {
		// the MCLK, XCLK are 120MHz on victoria card
		par->mclk_per = 1000000/120;
		par->xclk_per = 1000000/120;
		par->features &= ~M64F_MFB_FORCE_4;
	}

	/*
	 * Calculate mclk and xclk dividers, etc. The passed
	 * pixclock and bpp values don't matter yet, the vclk
	 * isn't programmed until later.
	 */
#ifndef __i386__
	// These were stolen from the working 2.4 kernel xlinit.c
	// This is what 'var_to_pll' used to do.
	if( (err = init_valid_pll_ct( info, 39726, &(pll.ct) ) ) )
		return err;
	if( M64_HAS(GTB_DSP) && (err = init_dsp_gt( info, 8, &(pll.ct) ) ) )
		return err;
	init_calc_pll_ct( info, &(pll.ct) );
#else
	// The current 'var_to_pll' assumes you have already called
	// 'init_from_bios' which only occurrs for __i386__
	if ((err = aty_pll_ct.var_to_pll(info, 39726, 8, &pll)))
		return err;
#endif

	aty_st_pll_ct(LVDS_CNTL0, 0x00, par);
	aty_st_pll_ct(DLL2_CNTL, card->dll2_cntl, par);
	aty_st_pll_ct(V2PLL_CNTL, 0x10, par);
	aty_st_pll_ct(MPLL_CNTL, MPLL_GAIN, par);
	aty_st_pll_ct(VPLL_CNTL, VPLL_GAIN, par);
	aty_st_pll_ct(PLL_VCLK_CNTL, 0x00, par);
	aty_st_pll_ct(VFC_CNTL, 0x1B, par);
	aty_st_pll_ct(PLL_REF_DIV, pll.ct.pll_ref_div, par);
	aty_st_pll_ct(PLL_EXT_CNTL, pll.ct.pll_ext_cntl, par);
	aty_st_pll_ct(SPLL_CNTL2, 0x03, par);
	aty_st_pll_ct(PLL_GEN_CNTL, 0x44, par);

	reset_clocks(par, &pll.ct, 0);
	mdelay(10);

	aty_st_pll_ct(VCLK_POST_DIV, 0x03, par);
	aty_st_pll_ct(VCLK0_FB_DIV, 0xDA, par);
	aty_st_pll_ct(VCLK_POST_DIV, 0x0F, par);
	aty_st_pll_ct(VCLK1_FB_DIV, 0xF5, par);
	aty_st_pll_ct(VCLK_POST_DIV, 0x3F, par);
	aty_st_pll_ct(PLL_EXT_CNTL, 0x40 | pll.ct.pll_ext_cntl, par);
	aty_st_pll_ct(VCLK2_FB_DIV, 0x00, par);
	aty_st_pll_ct(VCLK_POST_DIV, 0xFF, par);
	aty_st_pll_ct(PLL_EXT_CNTL, 0xC0 | pll.ct.pll_ext_cntl, par);
	aty_st_pll_ct(VCLK3_FB_DIV, 0x00, par);

	aty_st_8(BUS_CNTL, 0x01, par);
	aty_st_le32(BUS_CNTL, card->bus_cntl | 0x08000000, par);

	aty_st_le32(CRTC_GEN_CNTL, 0x04000200, par);
	aty_st_le16(CONFIG_STAT0, 0x0020, par);
	aty_st_le32(MEM_CNTL, 0x10151A33, par);
	aty_st_le32(EXT_MEM_CNTL, 0xE0000C01, par);
	aty_st_le16(CRTC_GEN_CNTL+2, 0x0000, par);
	aty_st_le32(DAC_CNTL, card->dac_cntl, par);
	aty_st_le16(GEN_TEST_CNTL, 0x0100, par);
	aty_st_le32(CUSTOM_MACRO_CNTL, 0x003C0171, par);
	aty_st_le32(MEM_BUF_CNTL, 0x00382848, par);

	aty_st_le32(HW_DEBUG, card->hw_debug, par);
	aty_st_le16(MEM_ADDR_CONFIG, 0x0000, par);
	aty_st_le16(GP_IO+2, 0x0000, par);
	aty_st_le16(GEN_TEST_CNTL, 0x0000, par);
	aty_st_le16(EXT_DAC_REGS+2, 0x0000, par);
	aty_st_le32(CRTC_INT_CNTL, 0x00000000, par);
	aty_st_le32(TIMER_CONFIG, 0x00000000, par);
	aty_st_le32(0xEC, 0x00000000, par);
	aty_st_le32(0xFC, 0x00000000, par);

#if defined(CONFIG_PM) || defined(CONFIG_PMAC_BACKLIGHT) || defined (CONFIG_FB_ATY_GENERIC_LCD)
	{
	int i;
	for (i=0; i<sizeof(lcd_tbl)/sizeof(lcd_tbl_t); i++) {
		aty_st_lcd(lcd_tbl[i].lcd_reg, lcd_tbl[i].val, par);
	}
	}
#endif

	aty_st_le16(CONFIG_STAT0, 0x00A4, par);
	mdelay(10);

	aty_st_8(BUS_CNTL+1, 0xA0, par);
	mdelay(10);
	
	reset_clocks(par, &pll.ct, 1);
	mdelay(10);

	// something about power management
	aty_st_8(LCD_INDEX, 0x08, par);
	aty_st_8(LCD_DATA, 0x0A, par);
	aty_st_8(LCD_INDEX, 0x08, par);
	aty_st_8(LCD_DATA+3, 0x02, par);
	aty_st_8(LCD_INDEX, 0x08, par);
	aty_st_8(LCD_DATA, 0x0B, par);
	mdelay(2);
	
	// enable display requests, enable CRTC
	aty_st_8(CRTC_GEN_CNTL+3, 0x02, par);
	// disable display
	aty_st_8(CRTC_GEN_CNTL, 0x40, par);
	// disable display requests, disable CRTC
	aty_st_8(CRTC_GEN_CNTL+3, 0x04, par);
	mdelay(10);

	aty_st_pll_ct(PLL_YCLK_CNTL, 0x25, par);

	aty_st_le16(CUSTOM_MACRO_CNTL, 0x0179, par);
	aty_st_le16(CUSTOM_MACRO_CNTL+2, 0x005E, par);
	aty_st_le16(CUSTOM_MACRO_CNTL+2, card->custom_macro_cntl>>16, par);
	aty_st_8(CUSTOM_MACRO_CNTL+1,
		 (card->custom_macro_cntl>>8) & 0xff, par);

	aty_st_le32(MEM_ADDR_CONFIG, card->mem_addr_config, par);
	aty_st_le32(MEM_CNTL, card->mem_cntl, par);
	aty_st_le32(EXT_MEM_CNTL, card->ext_mem_cntl, par);

	aty_st_8(CONFIG_STAT0, 0xA0 | card->mem_type, par);

	aty_st_pll_ct(PLL_YCLK_CNTL, 0x01, par);
	mdelay(15);
	aty_st_pll_ct(PLL_YCLK_CNTL, card->pll_yclk_cntl, par);
	mdelay(1);
	
	reset_clocks(par, &pll.ct, 0);
	mdelay(50);
	reset_clocks(par, &pll.ct, 0);
	mdelay(50);

	// enable extended register block
	aty_st_8(BUS_CNTL+3, 0x7B, par);
	mdelay(1);
	// disable extended register block
	aty_st_8(BUS_CNTL+3, 0x73, par);

	aty_st_8(CONFIG_STAT0, 0x80 | card->mem_type, par);

	// disable display requests, disable CRTC
	aty_st_8(CRTC_GEN_CNTL+3, 0x04, par);
	// disable mapping registers in VGA aperture
	aty_st_8(CONFIG_CNTL, aty_ld_8(CONFIG_CNTL, par) & ~0x04, par);
	mdelay(50);
	// enable display requests, enable CRTC
	aty_st_8(CRTC_GEN_CNTL+3, 0x02, par);

	// make GPIO's 14,15,16 all inputs
	aty_st_8(LCD_INDEX, 0x07, par);
	aty_st_8(LCD_DATA+3, 0x00, par);

	// enable the display
	aty_st_8(CRTC_GEN_CNTL, 0x00, par);
	mdelay(17);
	// reset the memory controller
	aty_st_8(GEN_TEST_CNTL+1, 0x02, par);
	mdelay(15);
	aty_st_8(GEN_TEST_CNTL+1, 0x00, par);
	mdelay(30);

	// enable extended register block
	aty_st_8(BUS_CNTL+3,
		 (u8)(aty_ld_8(BUS_CNTL+3, par) | 0x08),
		 par);
	// set FIFO size to 512 (PIO)
	aty_st_le32(GUI_CNTL,
		    aty_ld_le32(GUI_CNTL, par) & ~0x3,
		    par);

	// enable CRT and disable lcd
	aty_st_8(LCD_INDEX, 0x01, par);
	temp = aty_ld_le32(LCD_DATA, par);
	temp = (temp | 0x01) & ~0x02;
	aty_st_le32(LCD_DATA, temp, par);
	return 0;
}

Re: Atyfb questions and issues

[Daniël Mantione]

Op Mon, 15 Aug 2005, schreef Jim Ramsay:

> Of course.
>
> How about the replacement for 'xlinit.c' I have attached here?
>
> I noticed that the big difference between what the 2.4 kernel and 2.6
> kernel did is that the 'var_to_pll' (and its component functions) in
> 2.4 did a lot more probing than that in the 2.6 kernel.
>
> So I copied the relevant 2.4 bits for non-i386 archs, and replaced the
> call to 'var_to_pll' with the "new" stuff.
>
> This seems to work for me.  Enjoy!

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 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.

Daniël Mantione

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@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!"

Re: Atyfb questions and issues

[Daniël Mantione]

Op Mon, 15 Aug 2005, schreef Jim Ramsay:

> 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.

Yes, aty_valid_pll_ct in the pre-LCD calculation consists of two parts:
 * Calculation of the post divider for the chip and memory clock.
 * Calculation of the post divider for the pixel clock.

The the calculation of the post divider for the chip and memory clock
is part of the chip initialisation, and not of the video mode setting. It
didn't hurt though. However, in the post-LCD code there is an option to
prevent the driver from reclocking your chip and there are separate chip
and memory clocks. Therefore the calculation of the memory post divider is
done in mach64_ct.c near line 358 and the chip clock near line 391. This
code is fully equivalent to the original.

The calculation of the post divider for the pixel clock is still in
aty_valid_pll_ct.

Now, the only thing that aty_calc_pll_ct did, was to convert a multiplier
(1x, 2x, 4x or 8x) to a number that should be programmed into a register
(0, 1, 2 or 3). I use a more elegant way in the post-LCD code, and that is
a simple array lookup in the postdividers array.

In other words, all code of aty_valid_pll_ct and aty_calc_pll_ct is still
there and there should be no need to use the 2.4 code.

aty_dsp_gt is totally rewritten as I described in my previous e-mail.

> 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.

It won't affect i386 machines because of that. It will affect PowerPC
hardware which use Mach64 chips a lot.

We did a fix (display fifo size) into the table of chips to make an
Apple Wallstreet laptop work. That change was correct, but it does have
the effect that it no longer works with the old code.

> 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!

Afaik the driver falls back to default values in the chip table if
init_bios_setup isn't called or succesfull. But then there might still be
a need for a replacement for init_bios_setup. If the chip table does not
contain the right values for your system you should write a replacement.
If necessary, explicitly detect your machine and use hardcoded values.

Daniël