On 2002.03.10 15:55 Frank C. Earl wrote: > On Sunday 10 March 2002 11:44 am, José Fonseca wrote: > > ... > > 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. >
I look forward to check it out. > 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. I didn't fully understand the implications of above, but shouldn't the direct access to the chip registers still be denied to clients? > Mapping and unmapping a memory space is somewhat compute intensive. This one has to be compared to the time that takes to copy a buffer, unless there is a way to do it in a secure manner without copying or unmapping. > > -- > Frank Earl > José Fonseca _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
