Dave,
I turned on PC recording in kmmio. It reveals some interesting things
about what those indirect memory accesses are doing. First, all of the
calls to the 168/16C registers are in: MCIL_ModifyRegister (So it looks like
this is the Memory Controller that it is accessing.)
Next, I recorded the address of the function which called
MCIL_ModifyRegister:
read[18] -> 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
write[118] <- 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
write[138] <- 0x00000005 _ZN9GartRS48023InitializeGartRegistersEv
read[2b] -> 0x00000000 _ZN9GartRS48023InitializeGartRegistersEv
write[12b] <- 0x42040800 _ZN9GartRS48023InitializeGartRegistersEv
write[12c] <- 0x33b00000 _ZN9GartRS48023InitializeGartRegistersEv
read[39] -> 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
write[139] <- 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
read[38] -> 0x00000005 _ZN9GartRS48010EnableGartEv
write[138] <- 0x00000005 _ZN9GartRS48010EnableGartEv
read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
So, some interesting things come out of this:
I think that:
38/138 turns on the GART.
2e/12e flushs the Gart TLB
2c/12c The address of the GART table
2b/12b (?)
18/118 (?)
39/139 (?)
I'll have to look at your dump and compare. (Maybe we can find some size
differences).
The only thing that is really peculiar, is that when I look at the GART
table that 2c points to, it is MUCH too small.. Only 32*4 entries, which is
only enough to map 512k... (Also, the addresses are stored in big endian.. I
think.) I might be interesting to actually look at what is in these
addresses.
(BTW. I actually had to hack mmio so that it showed me the function who
called MCIL_ModifyRegister. I hope to have full backtraces soon... )
--Phil
On 2/21/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> Which would exactly fit between 0xCFFE0000 - 0xCFFFFFFF. Yes this is
an
> assumption, but some of the DRI code mentions that PCI express allocates
the
> GART table at the end of the frame buffer, so that is why I was thinking
it
> worked this way.
Can you dump that memory area? see if it has a GART table in it.. GART
tables usually are fairly easy to spot lots of page pointers..
>
> Ok.. I read that file. None of them seem to touch the card
directly.. The
> only bits that I found which actually touch the card are in radeon_cp.c
(at
> least the older git checkout that I have...)
ati_pcigart.c just creates the tables, the registers to poke are
differrent depending on the type of gart..
>
> When you say that the card reacts, are you referring to tickling these
> registers: RADEON_AIC_CNTL, RADEON_AIC_PT_BASE, RADEON_AIC_LO_ADDR,
> RADEON_AIC_HI_ADDR? (none of my fglrx traces (libsegfault or kmmio)
touch
> these registers...)
Yeah I just tried to see if a PCI GART worked, I didn't care if fglrx used
it or not,... there is probably something else necessary outside the
normal setup regs to get it to work I gave it up on it when it didn't work
out of the box..
Dave.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
