On 1/11/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote: > Hi All, > > I've been hacking away at the 200M driver without much success, and would > like to hear if other people with more radeon experience can help me. I have > things setup to use 128M of the sideport memory (and nothing else). I've > been both userspace (libsegfault) and kernelspace (kmmio) register tracing > to capture all of the accesses that the fglrx driver/library does to the > card. > > ... > There are many problems, but I want to start at the beginning. > First, the stipple pattern doesn't appear on the screen when X starts up. > As you may know, for radeon, this is done with DRI using indirect buffers to > draw the stipple. > > Oddly, the pattern never shows up on my screen AND the indirect pointer > (CP_IB_BASE) register is set to the value "000000000", so it doesn't look > like the CP is even executing the command. (When the firglx runs for a > while, this register is set to something sensible.. (0x58710000) ) > > I tried to avoid the whole "indirect buffer" issue, so on every call to the > indirect DRM ioctl, I issue the commands directly to the ring buffer and > return. (I just copied the values which X wrote to the indirect buffer.) > However, things still don't work correctly. > > CP > --- > 1) Could the CP be drawing this stuff, but putting it offscreen somewhere? > > 2) Could the command stream be wrong? > > 3) In the fgrlx 8.32.5 driver, the cp mode (RADEON_CP_CSQ_CNTL) is set to > (0x80000000), which doesn't correspond to ANY of the modes listed in the > radeon_regs.h file. Does anyone have any idea what that value means?
Keep in mind XPRESS support was added by trial and error; ati released no information about it at all. It's possible ati changed around some of the bit fields for various regs. Mode setting tends to stay the same across generations while drawing engines and command queues tend to get the upgrades. Back when ati released the original IGP chips they didn't work at all with the radeon driver and it wasn't until a big ati code drop that they were supported. I would go ahead and change the radeon driver to mimic what fglrx is doing until you can successfully not lock it up. The old r300 command stream dumper may be useful as well. Alex > > 4) Is there a simple command that I can issue to the CP to clear the screen > JUST to see if it is issuing any commands from the ring buffer at all? > > Ring Buffer > ---------------- > I'm beginning to suspect that the CP is just executing random commands, and > I happen to get lucky that things start up at all. > > 1) The fglrx driver never sets the (RADEON_CP_RB_RPTR_ADDR) register. If I > read the register back when fglrx is running, it is set to "0". > > What does that register indicate? > > GART > > 1) The fglrx driver also never sets ANY of the the pciexpress registers. (or > any of the RADEON_AIC_*) Also, if I try to read the PCI Express registers > when fglrx is running, the values are all set to zero. > > (Oddly, the PCIE index register: 0x00000030 is written to, but it is never > follwed by reads/write to 0x00000034... However, the radeon_drv.h file also > lists 0x00000030 as the bus control register, so maybe it is using it as > that. ) > > Is it possible that this card does use a GART? (Or is that crazy talk..) > > Thanks, > --Phil > ------------------------------------------------------------------------- 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
