From: <AKa...@t-...> - 2001-07-23 18:08:16
|
Hi! First I want to introduce myself to the list. I'm a student of computer science at Universitaet des Saarlandes, Germany. I have a laptop with an ATI Rage LT Pro and want it to be supported by the DRI. I've been listening to this list quite a while, but now after the summer term I've enough spare time to contribute. I followd Gareth's advise to align the descriptor table. Because I'm new to this and don't know any of the specifications of the Mach64 chipset I've chosen to align the table to a 64k boundery. I think I've achieved this (if I interpet my dmesg output correctly): [drm] AGP_BASE = 0x00000000 [drm] AGP_CNTL = 0x00000000 [drm] ALPHA_TST_CNTL = 0x00000000 [drm] [drm] BM_COMMAND = 0xc0000e50 [drm] BM_FRAME_BUF_OFFSET = 0x00f5fcab [drm] BM_GUI_TABLE = 0x00000000 [drm] BM_STATUS = 0x080e20ca [drm] BM_SYSTEM_MEM_ADDR = 0xbaf5fcc7 [drm] BM_SYSTEM_TABLE = 0xbaf5fca3 [drm] BUS_CNTL = 0x7b33a110 [drm] [drm] CLR_CMP_CLR = 0x00000000 [drm] CLR_CMP_CNTL = 0x00000000 [drm] CONFIG_CHIP_ID = 0xdc004c42 [drm] CONFIG_CNTL = 0x00003602 [drm] CONFIG_STAT0 = 0x00a10095 [drm] CONFIG_STAT1 = 0x00000000 [drm] CONFIG_STAT2 = 0x00008200 [drm] CRC_SIG = 0x00000000 [drm] CUSTOM_MACRO_CNTL = 0x003c0171 [drm] [drm] DP_BKGD_CLR = 0x00000000 [drm] DP_FRGD_CLR = 0xffffffff [drm] DP_MIX = 0x00070003 [drm] DP_PIX_WIDTH = 0x00040404 [drm] DP_SRC = 0x00000100 [drm] DP_WRITE_MASK = 0xffffffff [drm] DSP_CONFIG = 0x00380625 [drm] DSP_ON_OFF = 0x015805eb [drm] DST_CNTL = 0x00000003 [drm] DST_OFF_PITCH = 0x19000000 [drm] [drm] EXT_MEM_CNTL = 0x64000c01 [drm] [drm] FIFO_STAT = 0x00000000 [drm] [drm] GEN_TEST_CNTL = 0x00000000 [drm] GUI_CMDFIFO_DATA = 0x00000000 [drm] GUI_CMDFIFO_DEBUG = 0x001010a2 [drm] GUI_CNTL = 0x00000000 [drm] GUI_STAT = 0x00c00000 [drm] GUI_TRAJ_CNTL = 0x00000003 [drm] [drm] HOST_CNTL = 0x00000000 [drm] HW_DEBUG = 0x48803800 [drm] [drm] MEM_ADDR_CONFIG = 0x00000101 [drm] MEM_BUF_CNTL = 0x00382848 [drm] [drm] SCALE_3D_CNTL = 0x00000000 [drm] SCRATCH_REG0 = 0x04100400 [drm] SCRATCH_REG1 = 0x00800800 [drm] SETUP_CNTL = 0x31000000 [drm] SRC_CNTL = 0x00000000 [drm] [drm] TEX_CNTL = 0x00000000 [drm] TEX_SIZE_PITCH = 0x05555555 [drm] TIMER_CONFIG = 0x00000000 [drm] [drm] Z_CNTL = 0x00000100 [drm] Z_OFF_PITCH = 0x0a023280 [drm] [drm] Preparing table ... [drm] table[0] = 0x007ffe48 [drm] table[1] = 0x00010000 [drm] table[2] = 0xc0000020 [drm] table[3] = 0x00000000 [drm] data[0] = 0x000000a0 [drm] data[1] = 0x22222222 [drm] data[2] = 0x000000a0 [drm] data[3] = 0x22222222 [drm] data[4] = 0x000000a0 [drm] data[5] = 0x22222222 [drm] data[6] = 0x0000006d [drm] data[7] = 0x00000000 [drm] waiting for idle... [drm] waiting for idle... done. [drm] BUS_CNTL = 0x7b33a010 [drm] SRC_CNTL = 0x00000000 [drm] [drm] data = 0x00010000 [drm] table = 0x00080000 [drm] starting DMA transfer... [drm] waiting for idle... [drm] starting DMA transfer... done. [drm] waiting for idle 0... [drm:mach64_do_wait_for_idle] *ERROR* failed! GUI_STAT=0x00c00001 [drm] [drm] BUS_CNTL = 0x7b33a110 [drm] SRC_CNTL = 0x00000f00 [drm] PAT_REG0 = 0x11111111 [drm] [drm] GUI_CMDFIFO_DEBUG = 0x0013004c [drm] GUI_CMDFIFO_DATA = 0x00000003 [drm] FIFO_STAT = 0x00000000 [drm] [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 [drm] BM_SYSTEM_MEM_ADDR = 0x00010000 [drm] BM_COMMAND = 0xc0000020 [drm] BM_STATUS = 0x1b0860ca [drm] BM_SYSTEM_TABLE = 0xbaf5fca3 [drm] BM_HOSTDATA = 0x00000000 [drm] BM_ADDR/BM_DATA = 0x00000000 [drm] BM_GUI_TABLE = 0x00080010 [drm] BM_GUI_TABLE_CMD = 0x00000000 [drm] freeing memory. As you can see the addresses of table and data are muliples of 0x10000. But still the engine stays active... ;-( Could someone give me a hint how to proceed? I've looked at utah-glx code. There's mentioned mach64 Programmer's Guide, Section 8.10. I don't have it and it isn' that easy to get ( following the discussion ;-). So, could somebody cut and paste the relevant parts to this list? Thanks, Andreas Karrenbauer |
From: Frank C. E. <fe...@ai...> - 2001-07-24 02:12:48
|
On Monday 23 July 2001 12:09, Andreas Karrenbauer wrote: > [drm] PAT_REG0 = 0x11111111 DMA's not working in the code you're working with- the test setup Gareth's code put into the test buffer was code to set PAT_REG0 to 0x22222222 repeatedly. Set up a check of MACH64_BM_GUI_TABLE_CMD- check to see if it's taking what you're writing to it (I was having problems with that register always being zero on my machine- which means that at least with the setup I had, I wasn't mapped in the right spot...) -- Frank Earl |
From: <AKa...@t-...> - 2001-07-25 02:24:44
|
"Frank C. Earl" wrote: > > On Monday 23 July 2001 12:09, Andreas Karrenbauer wrote: > > > [drm] PAT_REG0 = 0x11111111 > > DMA's not working in the code you're working with- the test setup Gareth's > code put into the test buffer was code to set PAT_REG0 to 0x22222222 > repeatedly. Set up a check of MACH64_BM_GUI_TABLE_CMD- check to see if it's > taking what you're writing to it (I was having problems with that register > always being zero on my machine- which means that at least with the setup I > had, I wasn't mapped in the right spot...) hmm ... I've studied utah-glx code and fiddled a bit around with the code. Let's see if I understand what's going on there: MACH64_WRITE( MACH64_BM_GUI_TABLE_CMD, table ); /* This puts the physical adress of the descriptor table to the card. Though, the register stays zero as you said. But it seems that the value written to that reg are piped directly to MACH64_BM_GUI_TABLE (I tried out some different values). */ MACH64_WRITE( MACH64_SRC_CNTL, 0x00000f00 ); /* enables something, but I don't know what */ MACH64_WRITE( MACH64_DST_HEIGHT_WIDTH, 0); /* This GUI-Command kicks off the transfer. */ Okay so far so good. But what does the engine do now? It seems (checking the dmesg output) that now the descriptor table is loaded into the registers BM_FRAME_BUF_OFFSET, BM_SYSTEM_MEM_ADDR and BM_COMMAND. At this point data must be read. But how does the mach64 do that? I suppose a DMA-transfer to take a chunk of data from system memory and copy it to the device memory at the given address in one piece (or vice versa). But if the data is a control sequence this naive look makes no sence if there's not a kind of buffer at the destination address. Could someone gives me any details what the engine is doing there exactly? An other thing I'm wondering about is that the value in BM_GUI_TABLE is incremented by 0x10 in the meantime?! What's wrong there that the transfer is only executed till the descibed stage? -Andreas Karrenbauer |
From: Manuel T. <man...@so...> - 2001-07-26 19:53:34
|
Hello. I've not the documentation and also trying to understand how the mach64 works. El Miércoles 25 Julio 2001 03:25, Andreas Karrenbauer escribió: > "Frank C. Earl" wrote: > > On Monday 23 July 2001 12:09, Andreas Karrenbauer wrote: > > > [drm] PAT_REG0 = 0x11111111 > > > > DMA's not working in the code you're working with- the test setup > > Gareth's code put into the test buffer was code to set PAT_REG0 to > > 0x22222222 repeatedly. Set up a check of MACH64_BM_GUI_TABLE_CMD- check > > to see if it's taking what you're writing to it (I was having problems > > with that register always being zero on my machine- which means that at > > least with the setup I had, I wasn't mapped in the right spot...) > > hmm ... I've studied utah-glx code and fiddled a bit around with the > code. Let's see if I understand what's going on there: > > MACH64_WRITE( MACH64_BM_GUI_TABLE_CMD, table ); > > /* This puts the physical adress of the descriptor table to the card. > Though, the register stays zero as you said. But it seems that the value > written to that reg are piped directly to MACH64_BM_GUI_TABLE (I tried > out some different values). */ > > MACH64_WRITE( MACH64_SRC_CNTL, 0x00000f00 ); After looking to the Utah-glx code, this is equivalent to: MACH64_SRC_BM_ENABLE | MACH64_SRC_BM_SYNC | MACH64_SRC_BM_OP_SYSTEM_TO_REG anyway, I've replaced that line with: MACH64_WRITE( MACH64_SRC_CNTL, MACH64_READ(MACH64_SRC_CNTL) | MACH64_SRC_BM_ENABLE | MACH64_SRC_BM_SYNC | MACH64_SRC_BM_OP_SYSTEM_TO_REG ); I'm getting empirically a 0x00000f10, because SRC_CNTL had a 0x00000010 before the operation. The defines names are more or less self-explained (I hope). > > /* enables something, but I don't know what */ > > MACH64_WRITE( MACH64_DST_HEIGHT_WIDTH, 0); > > /* This GUI-Command kicks off the transfer. */ I suppose that the engine burst the DMA transfer because we have enabled it, so, no matter the command we are sending. It looks that o force the engine to start the DMA transfer a command is necessary. Could be this is a nonsense and I haven't understood anything. :'-( > > Okay so far so good. But what does the engine do now? It seems (checking > the dmesg output) that now the descriptor table is loaded into the > registers BM_FRAME_BUF_OFFSET, BM_SYSTEM_MEM_ADDR and BM_COMMAND. At > this point data must be read. But how does the mach64 do that? I suppose > a DMA-transfer to take a chunk of data from system memory and copy it to > the device memory at the given address in one piece (or vice versa). But > if the data is a control sequence this naive look makes no sence if > there's not a kind of buffer at the destination address. In this case, the data is a set of commands (the data array). That is what the buffer is storing, just commands: 1.-Set up the data in the DMA memory to transfer. 2.-Enable Bus Mastering. 3.-Set up the descriptors pointing to the data to transfer. 4.-You send a command to the engine to force the DMA transfer. The engine reads the descriptors (4K maximum), in any descriptor, as you can see in the Utah-GLX code (mach64dma.h) the DATA is always in the following format: ADDR (in MM offset format) DATA ADDR DATA ... and so on with a 4K maximum size. On the other hand, this chunks of data are accessed through descriptors, any of them built with 4 double words: BM_FRAME_BUF_OFFSET (Frame buffer offset) BM_SYSTEM_MEM_ADDR (Address of the DMAmable memory) BM_COMMAND (Size & flags) RESERVED (Always zero) in the code Gareth made for the DMA test in the mach64 branch, BM_COMMAND is equal to ( size | 0x40000000 | 0x80000000 ). The first flag says to the engine that it doesn't need to increment the target address (by default, the DMA engine tries to perform a blit operation), the second one is to inform that this is the last descriptor in the block. So, in this case, Gareth is only sending a descriptor, and the flags are 0xc0000000. > Could someone gives me any details what the engine is doing there > exactly? I suppose that trying to busmaster a DMA transfer from the information it's finding in the descriptor table. > An other thing I'm wondering about is that the value in BM_GUI_TABLE is > incremented by 0x10 in the meantime?! I think this happens everytime a descriptor is read, the BM_GUI_TABLE is incremented in 0x10, that would be the location of the following descriptor (if there was any). > What's wrong there that the transfer is only executed till the descibed > stage? > And one more time, I'm returning to the values in table: data[0] = 0x000000a0 data[1] = 0x22222222 data[2] = 0x000000a0 data[3] = 0x22222222 data[4] = 0x000000a0 data[5] = 0x22222222 data[6] = 0x0000006d data[7] = 0x00000000 So, looking at the header in GLX mach64dma.h file, the data is coded in this fashion: ADDR (in MM offset format) DATA So, I suppose that 0x000000a0 is the Memory Mapped offset of the MACH64_PAT_REG0, but in the mach64dma.h the define is: #define MACH64_PAT_REG0 0x0680 Isn't this supposed to be the MM offset ? I will try to get a lock on my machine replacing 0x000000a0 with 0x00000680, ;-)... No lock, but the same bad results. MACH64_PAT_REG0 is not been changed by the DMA transfer. Anyway, the BM_GUI_TABLE is incremented, so, could be that the transfer is taking place but we are coding the wrong commands that are messing the engine and locking it? When I try to execute again the test (after the first fail) it doesn't work anymore (I want to mind that BM_GUI_TABLE is always zero). Best regards. -- Manuel Teira |
From: Frank C. E. <fe...@ai...> - 2001-07-27 06:22:26
|
On Wednesday 25 July 2001 09:41, Manuel Teira wrote: > Hello. I've not the documentation and also trying to understand how the > mach64 works. You're doing pretty good, I'd say, based off you're studies of the Utah-GLX code. > After looking to the Utah-glx code, this is equivalent to: > > MACH64_SRC_BM_ENABLE | > MACH64_SRC_BM_SYNC | > MACH64_SRC_BM_OP_SYSTEM_TO_REG > > anyway, I've replaced that line with: > > MACH64_WRITE( MACH64_SRC_CNTL, > MACH64_READ(MACH64_SRC_CNTL) | > MACH64_SRC_BM_ENABLE | MACH64_SRC_BM_SYNC | > MACH64_SRC_BM_OP_SYSTEM_TO_REG ); > > I'm getting empirically a 0x00000f10, because SRC_CNTL had a 0x00000010 > before the operation. That's exactly the code I've went and stitched into my cleaned up version that I'm about to test (I got busy with some personal business tonight and didn't have time- I'm going to bed right after this e-mail's sent...). > The defines names are more or less self-explained (I hope). Pretty much. You're toggling the flag to tell it to do GUI bus-mastering, to syncronize the operation with the engine's operations, and to take the bus-mastering pass from the system memory. > I suppose that the engine burst the DMA transfer because we have enabled > it, so, no matter the command we are sending. It looks that o force the > engine to start the DMA transfer a command is necessary. Could be this is a > nonsense and I haven't understood anything. :'-( You've got it dead to rights. Once the whole setup sequence is done, it will do nothing but that operation unless you've messed up something in the setup. > in the code Gareth made for the DMA test in the mach64 branch, BM_COMMAND > is equal to ( size | 0x40000000 | 0x80000000 ). The first flag says to the > engine that it doesn't need to increment the target address (by default, > the DMA engine tries to perform a blit operation), the second one is to > inform that this is the last descriptor in the block. So, in this case, > Gareth is only sending a descriptor, and the flags are 0xc0000000. You've just about described everything that you ever needed from the programmer's guide- all on your own. The only thing missing is tidbit details about how the register/framebuffer aperture is laid out on Intel and PPC type machines and how you're supposed to operate the chip on a PPC machine. Now, if only you could gain as much insight into the registers... > Isn't this supposed to be the MM offset ? I will try to get a lock on my > machine replacing 0x000000a0 with 0x00000680, ;-)... No, MM offset format means that it expects the dword offset, not the byte offset- the values Gareth supplied are correct. There's macros in the Utah code and in this code that convert the byte offsets that we use for direct register writes into dword ones. In the case of the last command, I'd be leery of setting that register to zero like that. I'd be using the contents of the register before the pass with the bus-master disable flag set on them. -- Frank Earl |
From: Manuel T. <man...@so...> - 2001-07-25 12:58:21
|
El Lunes 23 Julio 2001 19:09, Andreas Karrenbauer escribió: > Hi! > > First I want to introduce myself to the list. I'm a student of computer > science at Universitaet des Saarlandes, Germany. I have a laptop with an > ATI Rage LT Pro and want it to be supported by the DRI. I've been > listening to this list quite a while, but now after the summer term I've > enough spare time to contribute. > > I followd Gareth's advise to align the descriptor table. Because I'm new > to this and don't know any of the specifications of the Mach64 chipset > I've chosen to align the table to a 64k boundery. I think I've achieved > this (if I interpet my dmesg output correctly): > > [drm] AGP_BASE = 0x00000000 > [drm] AGP_CNTL = 0x00000000 > [drm] ALPHA_TST_CNTL = 0x00000000 > [drm] > [drm] BM_COMMAND = 0xc0000e50 > [drm] BM_FRAME_BUF_OFFSET = 0x00f5fcab > [drm] BM_GUI_TABLE = 0x00000000 > [drm] BM_STATUS = 0x080e20ca > [drm] BM_SYSTEM_MEM_ADDR = 0xbaf5fcc7 > [drm] BM_SYSTEM_TABLE = 0xbaf5fca3 > [drm] BUS_CNTL = 0x7b33a110 > [drm] > [drm] CLR_CMP_CLR = 0x00000000 > [drm] CLR_CMP_CNTL = 0x00000000 > [drm] CONFIG_CHIP_ID = 0xdc004c42 > [drm] CONFIG_CNTL = 0x00003602 > [drm] CONFIG_STAT0 = 0x00a10095 > [drm] CONFIG_STAT1 = 0x00000000 > [drm] CONFIG_STAT2 = 0x00008200 > [drm] CRC_SIG = 0x00000000 > [drm] CUSTOM_MACRO_CNTL = 0x003c0171 > [drm] > [drm] DP_BKGD_CLR = 0x00000000 > [drm] DP_FRGD_CLR = 0xffffffff > [drm] DP_MIX = 0x00070003 > [drm] DP_PIX_WIDTH = 0x00040404 > [drm] DP_SRC = 0x00000100 > [drm] DP_WRITE_MASK = 0xffffffff > [drm] DSP_CONFIG = 0x00380625 > [drm] DSP_ON_OFF = 0x015805eb > [drm] DST_CNTL = 0x00000003 > [drm] DST_OFF_PITCH = 0x19000000 > [drm] > [drm] EXT_MEM_CNTL = 0x64000c01 > [drm] > [drm] FIFO_STAT = 0x00000000 > [drm] > [drm] GEN_TEST_CNTL = 0x00000000 > [drm] GUI_CMDFIFO_DATA = 0x00000000 > [drm] GUI_CMDFIFO_DEBUG = 0x001010a2 > [drm] GUI_CNTL = 0x00000000 > [drm] GUI_STAT = 0x00c00000 > [drm] GUI_TRAJ_CNTL = 0x00000003 > [drm] > [drm] HOST_CNTL = 0x00000000 > [drm] HW_DEBUG = 0x48803800 > [drm] > [drm] MEM_ADDR_CONFIG = 0x00000101 > [drm] MEM_BUF_CNTL = 0x00382848 > [drm] > [drm] SCALE_3D_CNTL = 0x00000000 > [drm] SCRATCH_REG0 = 0x04100400 > [drm] SCRATCH_REG1 = 0x00800800 > [drm] SETUP_CNTL = 0x31000000 > [drm] SRC_CNTL = 0x00000000 > [drm] > [drm] TEX_CNTL = 0x00000000 > [drm] TEX_SIZE_PITCH = 0x05555555 > [drm] TIMER_CONFIG = 0x00000000 > [drm] > [drm] Z_CNTL = 0x00000100 > [drm] Z_OFF_PITCH = 0x0a023280 > [drm] > [drm] Preparing table ... > [drm] table[0] = 0x007ffe48 > [drm] table[1] = 0x00010000 > [drm] table[2] = 0xc0000020 > [drm] table[3] = 0x00000000 > [drm] data[0] = 0x000000a0 > [drm] data[1] = 0x22222222 > [drm] data[2] = 0x000000a0 > [drm] data[3] = 0x22222222 > [drm] data[4] = 0x000000a0 > [drm] data[5] = 0x22222222 > [drm] data[6] = 0x0000006d > [drm] data[7] = 0x00000000 > [drm] waiting for idle... > [drm] waiting for idle... done. > [drm] BUS_CNTL = 0x7b33a010 > [drm] SRC_CNTL = 0x00000000 > [drm] > [drm] data = 0x00010000 > [drm] table = 0x00080000 > [drm] starting DMA transfer... > [drm] waiting for idle... > [drm] starting DMA transfer... done. > [drm] waiting for idle 0... > [drm:mach64_do_wait_for_idle] *ERROR* failed! GUI_STAT=0x00c00001 > [drm] > [drm] BUS_CNTL = 0x7b33a110 > [drm] SRC_CNTL = 0x00000f00 > [drm] PAT_REG0 = 0x11111111 > [drm] > [drm] GUI_CMDFIFO_DEBUG = 0x0013004c > [drm] GUI_CMDFIFO_DATA = 0x00000003 > [drm] FIFO_STAT = 0x00000000 > [drm] > [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 > [drm] BM_SYSTEM_MEM_ADDR = 0x00010000 > [drm] BM_COMMAND = 0xc0000020 > [drm] BM_STATUS = 0x1b0860ca > [drm] BM_SYSTEM_TABLE = 0xbaf5fca3 > [drm] BM_HOSTDATA = 0x00000000 > [drm] BM_ADDR/BM_DATA = 0x00000000 > [drm] BM_GUI_TABLE = 0x00080010 > [drm] BM_GUI_TABLE_CMD = 0x00000000 > [drm] freeing memory. > > As you can see the addresses of table and data are muliples of 0x10000. > But still the engine stays active... ;-( Yes, I've got the same results with 16K alignments, after the DMA burst, the BM_GUI_TABLE is 0x10 after the descriptor table. Frank Earl said me that this is what we have to expect. After that, my engine is never idle (with GUI_STAT=0x02000001). > > Could someone give me a hint how to proceed? I've looked at utah-glx > code. There's mentioned mach64 Programmer's Guide, Section 8.10. I don't > have it and it isn' that easy to get ( following the discussion ;-). > So, could somebody cut and paste the relevant parts to this list? That will be great, if somebody could throw some light into this. But the Programmer's Manual is not public, and ATI is rejecting my attempts to get it (actually, they are not answering me, and I also tried with different names. ;-) ). I suppose that the people that have the documentation have been forbbiden by ATI to give the manual to other people. I've been looking at the UTAH-GLX timeout code and it's a bit different. I'll try to look at this again, but I suppose that the if LSB of GUI_STAT is set, the engine is busy, and that is all. Could the lock have something to do with the DMA commands we are sending to the card? Gareth, could you illustrate us about the commands? > > Thanks, > Andreas Karrenbauer > Best regards. -- Manuel Teira. |
From: Manuel T. <man...@so...> - 2001-07-25 12:58:23
|
El Martes 24 Julio 2001 22:15, Frank C. Earl escribió: > On Monday 23 July 2001 12:09, Andreas Karrenbauer wrote: > > [drm] PAT_REG0 = 0x11111111 > > DMA's not working in the code you're working with- the test setup Gareth's > code put into the test buffer was code to set PAT_REG0 to 0x22222222 > repeatedly. Set up a check of MACH64_BM_GUI_TABLE_CMD- check to see if > it's taking what you're writing to it (I was having problems with that > register always being zero on my machine- which means that at least with > the setup I had, I wasn't mapped in the right spot...) I'm suffering the same problem. My MACH64_GUI_TABLE is table+0x10, but MACH64_BM_GUI_TABLE is always zero. Are you sure we have to expect the last command in the DMA buffer in MACH64_BM_GUI_TABLE? What is the last command expected to do: data[6] = 0x0000006d data[7] = 0x00000000 Best regards. -- Manuel Teira |
From: <AKa...@t-...> - 2001-07-25 13:20:06
|
Manuel Teira wrote: > Are you sure we have to expect the last command in the DMA buffer in > MACH64_BM_GUI_TABLE? What is the last command expected to do: > data[6] = 0x0000006d > data[7] = 0x00000000 IMHO this command sets the BM_SRC_CNTL back to 0x0. Have a look at Utah-glx code of mach64dma.h. There are macros like ADRINDEX and MMSELECT. They convert the byte offset into dword offset and vice versa (roughly speaking). The banks they are on is concerned, too. So we have data[6] = 0x0000006d. This leads to MMSELECT(6d) = 0x5B4 which is the offset of BM_SRC_CNTL. This register should be set to data[7] = 0x0. The same holds for 0xa0 -> 0x680 PAT_REG0. -Andreas Karrenbauer |
From: Frank E. <fe...@ai...> - 2001-07-25 21:21:02
|
On Wednesday 25 July 2001 08:21, Andreas Karrenbauer wrote: > IMHO this command sets the BM_SRC_CNTL back to 0x0. That is exactly what it's doing. In fact, one of you ought to add a check for this condition in the idle out code (I don't reccomend doing this for our production code going into CVS, and I'd be cleaning up the code in init to do the RIGHT thing as you're messing things up doing it this way.)- if you look at the Utah-GLX code for the DMA wait, you'll see the edits I made for that. > Have a look at Utah-glx code of mach64dma.h. There are macros like > ADRINDEX and MMSELECT. They convert the byte offset into dword offset > and vice versa (roughly speaking). The banks they are on is concerned, > too. > So we have data[6] = 0x0000006d. This leads to MMSELECT(6d) = 0x5B4 > which is the offset of BM_SRC_CNTL. This register should be set to > data[7] = 0x0. The same holds for 0xa0 -> 0x680 PAT_REG0. There's code there in mach_drv.h that does the same thing, just under different names. Once I clean up my machine tonight or tomorrow, I'm re-applying Manuel's patches and coming up with a suitable allocator based off of these discussions, I think the game's afoot. -- Frank Earl |
From: Frank E. <fe...@ai...> - 2001-07-25 21:10:34
|
On Tuesday 24 July 2001 21:25, Andreas Karrenbauer wrote: > MACH64_WRITE( MACH64_SRC_CNTL, 0x00000f00 ); > > /* enables something, but I don't know what */ That tells the engine that you're doing a GUI master (slight difference in how the bus-mastering engine does while operating...) operation and that you're going from host to the registers. > MACH64_WRITE( MACH64_DST_HEIGHT_WIDTH, 0); > > /* This GUI-Command kicks off the transfer. */ > > Okay so far so good. But what does the engine do now? It seems (checking > the dmesg output) that now the descriptor table is loaded into the > registers BM_FRAME_BUF_OFFSET, BM_SYSTEM_MEM_ADDR and BM_COMMAND. At > this point data must be read. But how does the mach64 do that? I suppose > a DMA-transfer to take a chunk of data from system memory and copy it to > the device memory at the given address in one piece (or vice versa). But > if the data is a control sequence this naive look makes no sence if > there's not a kind of buffer at the destination address. > Could someone gives me any details what the engine is doing there > exactly? The engine proceeds to pull values from out of the descriptor table as soon as that last write operation is performed- this is by ATI's design. The values placed in the data areas described by the descriptor table are MMIO dword offset for the register followed by the data to be put into that register. The engine treats the data in the areas defined by the descriptor table as an enormous command fifo. It grabs the first dword and assumes it's an offset in dwords from the base of the register aperture. It then assumes that the second dword is the data that is supposed to be written to that register and does just that. It continues until it reaches the end of the descriptor table. Note that this doesn't turn off the GUI master setup and any attempt to write to the GUI registers will re-fire the entire descriptor table. In order to avoid this problem in Utah-GLX, we mprotected the register region during the pass and placed a shutdown command (disabling bus mastering by toggling the bus master disable flag in the control register) at the end along with restoring selected old register values that we had upon entry. > An other thing I'm wondering about is that the value in BM_GUI_TABLE is > incremented by 0x10 in the meantime?! > What's wrong there that the transfer is only executed till the descibed > stage? I don't remember enough about this to comment right at the moment and I don't happen to have my docs with me at work. Let me get back with you on that one- I'm picking up the pieces of another hectic week so I've not been doing a lot with this until last night and I didn't get very far because of time. -- Frank Earl |
From: <AKa...@t-...> - 2001-07-25 22:43:58
|
Frank Earl wrote: > > An other thing I'm wondering about is that the value in BM_GUI_TABLE is > > incremented by 0x10 in the meantime?! > > What's wrong there that the transfer is only executed till the descibed > > stage? > > I don't remember enough about this to comment right at the moment and I don't > happen to have my docs with me at work. Let me get back with you on that > one- I'm picking up the pieces of another hectic week so I've not been doing > a lot with this until last night and I didn't get very far because of time. Refering utah-code I suppose that the lowest XXX bits are reserved for flags or something like that. This explains the need for aligned tables: having lowest address bits as zeros. In the case of a 16k descriptor table we have space for 14 bits. Looking at utah-code the lowest 2 bits telss the table size. But what's about the other 12? -Andreas Karrenbauer |
From: <AKa...@t-...> - 2001-07-26 00:38:54
|
Frank Earl wrote: > > On Tuesday 24 July 2001 21:25, Andreas Karrenbauer wrote: > > > MACH64_WRITE( MACH64_SRC_CNTL, 0x00000f00 ); > > > > /* enables something, but I don't know what */ > > That tells the engine that you're doing a GUI master (slight difference in > how the bus-mastering engine does while operating...) operation and that > you're going from host to the registers. Ahh, I see 0xf00 means 0xc00 | 0x200 | 0x100 wich is MACH64_SRC_BM_OP_SYSTEM_TO_REG | ...BM_SYNC | ...BM_ENABLE When I *leave out* the SYNC-flag (changing 0x0000f00 to 0x00000d00) I *got rid* of that nasty waiting for idle thing. Hence, it is rather a *SYNCRONISATION* problem. Could somebody else test this and report wether the machine stays busy or not? Unfortunately the transfer to PAT_REG0 isn't performed either. -Andreas Karrenbauer |
From: Manuel T. <man...@so...> - 2001-07-27 20:33:29
|
El Jueves 26 Julio 2001 01:39, Andreas Karrenbauer escribió: > Frank Earl wrote: > > On Tuesday 24 July 2001 21:25, Andreas Karrenbauer wrote: > > > MACH64_WRITE( MACH64_SRC_CNTL, 0x00000f00 ); > > > > > > /* enables something, but I don't know what */ > > > > That tells the engine that you're doing a GUI master (slight difference > > in how the bus-mastering engine does while operating...) operation and > > that you're going from host to the registers. > > Ahh, I see 0xf00 means 0xc00 | 0x200 | 0x100 wich is > MACH64_SRC_BM_OP_SYSTEM_TO_REG | ...BM_SYNC | ...BM_ENABLE > > When I *leave out* the SYNC-flag (changing 0x0000f00 to 0x00000d00) I > *got rid* of that nasty waiting for idle thing. Hence, it is rather a > *SYNCRONISATION* problem. Could somebody else test this and report > wether the machine stays busy or not? What is the exact function of the Sync Flag? I've tested it and had the same results: The machine didn't stay busy, but the DMA transfer is not taking place (PAT_REG0!=0x22222222). I'm sorry if my mails are not reaching you as fast as it was desirable, but I'm on holidays and only getting my mail once every two days. > > Unfortunately the transfer to PAT_REG0 isn't performed either. > -- Manuel Teira |
From: <AKa...@t-...> - 2001-07-27 20:59:51
|
Manuel Teira wrote: > What is the exact function of the Sync Flag? > I've tested it and had the same results: The machine didn't stay busy, but > the DMA transfer is not taking place (PAT_REG0!=0x22222222). I don't know. First I thought that it is responsible to sync dma-cycles with gui-commands. But if I leave it out this sync is done though. > I'm sorry if my mails are not reaching you as fast as it was desirable, but > I'm on holidays and only getting my mail once every two days. That doesn't matter. I'm on holydays, too. I noticed one additional thing: the dma is working only in one way for me: from the card to the system (memory) that means reg_to_system and frame_to_system (or flags (2 << 10) and (0 << 10) in addition with 0x100) but it doesn't work the other way (1 << 10) locks my hardware completly and (3 << 10) doesn't seem to have any effect. -Andreas Karrenbauer |
From: <AKa...@t-...> - 2001-07-27 00:06:39
|
Frank Earl wrote: > The engine proceeds to pull values from out of the descriptor table as soon > as that last write operation is performed- this is by ATI's design. The > values placed in the data areas described by the descriptor table are MMIO > dword offset for the register followed by the data to be put into that > register. The engine treats the data in the areas defined by the descriptor > table as an enormous command fifo. It grabs the first dword and assumes it's > an offset in dwords from the base of the register aperture. It then assumes > that the second dword is the data that is supposed to be written to that > register and does just that. It continues until it reaches the end of the > descriptor table. Note that this doesn't turn off the GUI master setup and > any attempt to write to the GUI registers will re-fire the entire descriptor > table. In order to avoid this problem in Utah-GLX, we mprotected the > register region during the pass and placed a shutdown command (disabling bus > mastering by toggling the bus master disable flag in the control register) at > the end along with restoring selected old register values that we had upon > entry. There's one strong argument against this theory: Assume that there are disturbing GUI-commands wich are send in the time between kick-off and idle check that are supposed to fire of DMA again. I comment out the kick-off line in the code. By our assumption the DMA-transfer must be kicked-off though. But it isn't. The engine stays idle. Contradiction. Therefore this hypothesis is wrong. Or did I miss something? -Andreas Karrenbauer |