Roland,

On 1/16/07, Roland Scheidegger <sroland@tungstengraphics.com> wrote:
Phillip Ezolt wrote:
> (A simple explanation about the view of memory from the graphics card
> vs. the system would be helpful.  I found the following, but I could use
> more details:
> http://lists.freedesktop.org/archives/xorg/2005-May/007673.html)
>
> NOTE:The fglrx 8.32.5 driver makes NO calls to the following registers
> (I have a 200M w/128M sideport and no UMA):
> RADEON_AIC_STAT,RADEON_AIC_PT_BASE,RADEON_AIC_TLB_ADDR,
> RADEON_AIC_TLB_DATA
> -or-
> RADEON_PCIE_TX_DISCARD_RD_ADDR_LO,RADEON_PCIE_TX_GART_BASE,
> RADEON_PCIE_TX_GART_START_LO,RADEON_PCIE_TX_GART_END_LO,
> RADEON_PCIE_TX_GART_CNTL,
>
> However, driver does set RADEON_CP_CSQ_CNTL to 0x80000000, which is not
> defined anywhere that I've found...
fglrx always writes a 0x8 there, even on old r200 based chips.

Ok... I won't worry about it then.

>     another quick hack
>     method might be to place the CP in the reserved framebuffer memory (as
>     it is all UMA) and see if that works....
>
>
> In my BIOS, I've configured things so that I have no UMA memory and only
> 128MB of sideport. (If I turn on UMA, the 8.32.5 driver gets
> unstable...)   Does this mean that I shouldn't be using the GART at all?
>
> The card expects the ring buffer to be at 0x58000000.. (The FB begins at
> 0x50000000... I think that this is a bus address..)
>
> How do I get that region mmaped into my virtual address space, so that
> the kernel can actually write commands to the proper location?
Looks like the chip doesn't actually have neither pci nor pcie gart,
(maybe pci gart but not used). This would be completely normal for a AGP
based chip, does the driver write to RADEON_AGP_BASE?

Roland

No.  It doesn't..   There are no reads or writes to 0x00000170.  However, if I read back the
RADEON_AGP_BASE value when running fglrx is it set to: 0x58000000. (I can't explain that...)

Also, when I set the Xorg's RADEON_AGP_BASE value to: 0x58000000 (rather than 0x00000000), I am able to get the X server to startup.  (Maybe Xorg clears this?)

If it is 0: The Xserver just hangs waiting for the CP to be ready. (That's what's current in git..)

If I set it to 0x58000000: The Xserver starts up, the CP read/write pointers advance, but the commands don't actually get executed.

Cheers,
--Phil