On 10/22/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
> Thanks for answering my questions. Sorry I'm a little slow to respond.
> I can usually only work on this when everyone in the house is asleep. (That
> doesn't come that often..)
>
>
> > You'd probably want to configure the MC in the DDX (xf86-video-ati)
> > although you may have to coordinate with the drm if things like the
> > memory maps change. You shouldn't need to mess with the 3D driver
> > (mesa). The DDX sets up the card, sets modes and handles 2D accel and
> > overlays. The drm provides secure access to the card in the kernel
> > for things like DMA and command submission. The 3D mesa driver
> > translates OpenGL to card specific commands and then feeds the
> > commands to the drm.
>
> I greped through a copy of xf86-video-ati that I checked out of git. It
> seems that R300_MC_IND_INDEX is only manipulated in RADEONInitDispBandwidth.
> Are there some other places I am missing?
The radeon driver doesn't really mess with the memory controller
registers. It relies on the bios/chip defaults. I'm not even sure
messing with the MC stuff on the XPRESS chips will help. We're just
guessing here.
>
> (Or is there something else I should be looking for?)
> >
> > I shouldn't be too hard to add support for the indirect MC regs to
> > radeontool or another dumper. The indirect MC regs are accessed via
> > the MC index reg at MMIO offset 0x01F8 and the MC data reg at MMIO
> > offset 0x01FC. You specify the MC reg you want in the MC index reg
> > and then you can read/write to that reg via the MC data reg. bits 5:0
> > of the MC index reg specify the MC reg. bit 8 is the write enable
> > bit. You should be able to use the INPLL/OUTPLL code in the radeon
> > DDX as a model. the only difference is the PLL write enable bit is 7
> > rather than 8. The PCIE regs are indexed as well IIRC, but once
> > again, I'm not too familiar with them.
>
> Alright, so I took the radeontool and tried to make this happen.
>
> First the interesting things:
>
> fglrx (8.24.8)
> --------------------------
> RADEON_MC_AGP_LOCATION=5bff5800
> RADEON_MC_FB_LOCATION=57ff4800
> RADEON_MC_STATUS=00080001
> R300_MC_INIT_MISC_LAT_TIMER=f0001100
>
> xorg-x11-drv-ati-6.5.8.0-1
> -----------------------
> RADEON_MC_AGP_LOCATION=ffffffc0
> RADEON_MC_FB_LOCATION=57ff4800
> RADEON_MC_STATUS=00090005
> R300_MC_INIT_MISC_LAT_TIMER=f0000000
>
> Where are the defines that I can use to interpret these results?
> ..
No one with databooks has added them to the driver yet. It looks like
fglrx always bumps up the display priority in
R300_MC_INIT_MISC_LAT_TIMER. We do the same thing, but only if you
specify displaypriority "high". see RADEONInitDispBandwidth().
Perhaps we should alway bump teh priority in teh open driver as well.
Also the AGP stuff is not set up the same since by default the DRI is
not enabled on XPRESS chips. Plus I think they are PCIE based anyway.
If you want to test the opensource 3D driver, you'll have to enable it
in the DDX (xf86-video-ati) and remove the checks from the 3D driver
(r300 in mesa) that keep it from loading on XPRESS hardware.
>
> When I tried to read the MC regs as you specified above, I run into
> some problems.
>
> Two Problems:
> 1) If write the index, and then read it back, it is as if
> somebody zeroed bits 3:1 of the value that I wrote.
>
> 2) All of the reads to R300_MC_IND_DATA return "0".
>
> Questions:
> 1) Am I doing anything obviously wrong? (Code below)
> 2) Is a value of "0" reasonable for these registers?
>
> NOTE: I have another laptop w/ATI that IS supported by the DRIdrivers. I'm
> gonna try to run the dumper on that an see if the
> results are different. (This should help me figure out if my radentool code
> is bad, or the XPRESS really does set everything to zero..)
>
> Here's my code (Based on PLLIN /OUT as you suggested):
>
I'm not sure what the default settings of the registers are off hand.
It probably varies from card to card. Also from the documentation I
have the MC registers start at index 0x18 and go to 0x2F (each one is
32 bits). That may explain the zeros you were seeing. As for the MC
INDEX reg, I don't know that it retains the index on read back. I
wouldn't worry about that.
> "
> #define R300_MC_IND_INDEX 0x01f8
> # define R300_MC_IND_ADDR_MASK 0x3f
> #define R300_MC_IND_DATA 0x01fc
>
>
> #define OUTREG8(offset, val) *(volatile unsigned char *)(((unsigned
> char*)(radeon_cntl_mem)) + (offset)) = (val)
> #define INREG(offset) *(volatile unsigned long *)(void *)(((unsigned
> char*)(radeon_cntl_mem)) + (offset))
>
> unsigned int RADEONINMC(int addr)
> {
> unsigned int data;
>
> OUTREG8(R300_MC_IND_INDEX, (addr & R300_MC_IND_ADDR_MASK));
> data = INREG(R300_MC_IND_DATA);
>
> printf("Index(Read from R300_MC_IND_INDEX): %lx ",
> INREG(R300_MC_IND_INDEX));
>
> return data;
> }
>
> void radeon_memory_controller(void)
> {
> unsigned int i;
> for (i=0;i<=0x3f;i++)
> {
> printf("Index(written to R300_MC_IND_INDEX): %x ", i);
> printf("R300_MC_IND_DATA: %x\n", RADEONINMC(i));
> }
> }
>
>
> Output:
> "
> ....
> Index(written to R300_MC_IND_INDEX): 0 Index(Read from R300_MC_IND_INDEX): 0
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 1 Index(Read from R300_MC_IND_INDEX): 1
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 2 Index(Read from R300_MC_IND_INDEX): 0
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 3 Index(Read from R300_MC_IND_INDEX): 1
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 4 Index(Read from R300_MC_IND_INDEX): 0
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 5 Index(Read from R300_MC_IND_INDEX): 1
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 6 Index(Read from R300_MC_IND_INDEX): 0
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 7 Index(Read from R300_MC_IND_INDEX): 1
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 8 Index(Read from R300_MC_IND_INDEX): 8
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): 9 Index(Read from R300_MC_IND_INDEX): 9
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): a Index(Read from R300_MC_IND_INDEX): 8
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): b Index(Read from R300_MC_IND_INDEX): 9
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): c Index(Read from R300_MC_IND_INDEX): 8
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): d Index(Read from R300_MC_IND_INDEX): 9
> R300_MC_IND_DATA: 0
> Index(written to R300_MC_IND_INDEX): e Index(Read from R300_MC_IND_INDEX): 8
> R300_MC_IND_DATA: 0
> ....
> "
>
> > >
> > > Is there an overview of how radeons are laid out? I've looks through
> some
> > > of the DRI documentation (
> > > http://dri.freedesktop.org/wiki/Documentation), but
> none
> > > seem to reference the radeon specifically.
> >
> > what do you mean by "laid out"? :)
> >
> > most of the configuration is done via MMIO and things like 2D and 3D
> > are done via the command processor which is basically a buffer you
> > feed commands to.
>
>
> Sorry. I wasn't clear. I am really trying to figure out how the MC fits
> in.
>
> What is it responsible for? The speed of the memory access? Managing where
> textures live? (On card memory? In system memory?)
The memory controller handles all memory (FB and AGP/PCI/PCIE) related
activities on the radeon. The GPU is basicaly a specialized mini CPU.
Different parts of the chip vie for access to memory (display
controllers, pixel pipelines, etc.). The MC configuration registers
allow you to tweak the controller (everything from latencies, timing,
cache control, DRAM driving strength, etc. It's fairly complicated,
and I think is generally best left to the bios. I'd be careful
changing the MC regs unless you are reasonably sure what you are
doing. I take no responsibility for anyone who hoses their hardware.
>
> Also, in my BIOS, I can reserve system memory for the graphics card. How
> does the driver know about it/what does it do with the information?
>
> (ex: The kernel sees the space is reserved by the BIOS, so it reserves it as
> well, the ATI driver asks the kernel about the reserved space, and then uses
> it..)
>
> What changes if I adjust that value?
Give it a shot and see what happens. I've heard reports of users
having success with the the DRI using fglrx and setting the FB size in
the bios to a reasonably large level. If you can get the DRI going
with fglrx, you might just want to dump the regular MMIO regs and we
can see if anything interesting jumps out at us. You might also want
to try some of the radeon command buffer dumpers from the old r300
project with fglrx. I'm not sure anyone has looked at those since DRI
support for XPRESS chips was added to fglrx. It would be alot easier
to not have to mess with the MC regs.
>
> Thanks for the answers,
No problem.
Alex
> Cheers,
> --Phil
>
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
