On Sunday 10 March 2002 11:44 am, José Fonseca wrote: > I really don't know much about that, since it must happened before I > subscribed to this mailing list, but perhaps you'll want to take a look to > the Utah-GLX and this list archives. You can get these archives in mbox > format and also filtered with just the messages regarding mach64 at > http://mefriss1.swan.ac.uk/~jfonseca/dri/mailing-lists/
The problem was that the XAA driver for mach64 was setting the FIFO size up for some reason and it was leaving the chip in a state that wouldn't work for the DMA mode. If we set the size back to the default setting before we do the first DMA pass, everybody's happy. I suspect if we got with the developer of the XAA driver we can sell him on leaving that setting alone in the driver's setup. Sorry for being silent for so long gang. Been, yet again, crushed under with lovely personal business. I have started a new branch (mach64-0-0-3-dma-branch), and I'm actually putting the hacks I've been playing with into a unified DMA framework. I should be putting the first updates to the branch in over the next couple of days. Of note, when I did find some spare time, I ran tests on what we needed to do to secure the chip's DMA path. I found out some interesting facts. It will accept any values written to the registers. It will not act on any of those settings during the DMA pass unless they're a GUI specific operation when it's doing a command-type DMA. It will not act on many of the settings after a DMA pass is complete. It will not let you set up any sort of DMA pass during the operation. Junk commands, by themselves, do not seem to hose up the engine in operation. Mapping and unmapping a memory space is somewhat compute intensive. -- Frank Earl _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
