On 2002.05.03 17:08 Leif Delgass wrote: > On Fri, 3 May 2002, José Fonseca wrote: > > > As I was studying the specs and code to be able to understand and reply > to > > Leif's previous post (which I haven't completed yet..), I noticed at > the > > same time a bug and a feature which could mean that blind client > buffering > > could be insecure after all. > > > > The bug is that we should be using MACH64_BM_GUI_TABLE and not > > MACH64_BM_GUI_TABLE_CMD when setting up the GUI master operation. The > > difference between the two is that the later is queued in the FIFO and > the > > former not, and we really don't want this as it could get in the way > later. > > I think the reason for the alias is that the card increments the > GUI_TABLE_ADDR @ BM_GUI_TABLE as it consumes descriptors, so writing to > BM_GUI_TABLE could disrupt a DMA pass in progress. Using the alias > ensures that the commands already in the FIFO/command buffers are > processed before changing the table address.
So you think that it's less prone to error use the BM_GUI_TABLE_CMD alias to setup the GUI master operation. > However, as you say below, > it could potentially be used inside a command buffer as well. > > > Only commands which are on block 0 of MMIO region can be streamed into > a > > GUI master operation, as said in the BM_DATA register spec (8-11). > > This can't be right since the setup engine registers are in block 1 and > we > are using them in a GUI master op. That's what BUS_EXT_REG_EN @ BUS_CNTL > is for. Good point. Although it's not documented anywhere that BUS_EXT_REG_EN @ BUS_CNTL has any relation with the GUI master operation (especially because during a GUI master operation the registers are not written trhough the apperture but internally through BM_ADDR/BM_DATA). > ... > > btw, I also noticed that HOST_CNTL has a bit for big-endian translation > of > host data. At 15 and 16bpp, it swaps bytes within each word and at 32bpp > it reverses the order of the 4 bytes within each dword. This might fix > Peter's texture problem. It's still not clear that this will solve Peter's problem, because, assuming the textures are 16bit, the words are swaped, but _not_ the bytes. The question is where did the bytes got swapped? I think Mesa probably stores pixels in little endian format, or doesn't even try to change the pixel format. If so, how did the other drivers addressed this problem. (Note these are retorical question as I just didn't had the time to look the answers in the code - I'm still a little more concerned with the MMIO on PowerPC architecture). > ... > > Yeah, the first thing is to determine if it's really possible to kick off > a second DMA pass from within a DMA buffer. > I'll report when I get some results. José Fonseca _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
