On 2002.05.25 20:36 Frank C. Earl wrote: > On Saturday 25 May 2002 11:48 am, José Fonseca wrote: > > > So if you can't secure it in the end, your extra effort will be in > vain. > > I just thought of something to try to change the nature of the test case > problem. What happens if you have a second descriptor of commands that > merely resets the DMA engine settings to what they should be for the > third > descriptor? I'd say it'd depend on what the chip was actually doing- > what do you guys think?
You mean, setting the descriptor to the right value in between? hmm... I doubt that it in the middle works because as Leif noticed, the changes that we make to BM_GUI_TABLE only affect the descriptor that is two entries ahead, so it would be too late... ..but your idea in principal is quite ingenious! What if we just fill the last 8 bytes of each 4K block with that command to reset the value of BM_GUI_TABLE? So even if the client tries to mess things up, we would put it right in the end. Of course that it would be a pain [to code for] to reserve 8 bytes on the end of each 4k block, but it's doable [It would also be a pain to code the kernel unmap/verification routine] This means that not only the client can't mess up the descriptor table, but they can't tamper with BM_GUI_TABLE, so we can also still use it as a progression meter [in both implementations]. José Fonseca _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
