From: <man...@so...> - 2001-07-31 16:26:40
|
Hello again. I'd like to summarize the results I'm getting and to compare then with you, people testing the mach64 DRI pre-alpha driver, regarding DMA setup. The last modification I've made is: MACH64_WRITE( MACH64_BUS_CNTL, MACH64_READ( MACH64_BUS_CNTL ) | MACH64_BUS_EXT_REG_EN ); this is, enabling the second block of MM registers, as you can see in the Utah-GLX driver ( though this was already made in the direct writing of this register: MACH64_WRITE( MACH64_BUS_CNTL, 0x7b33a010 ); ). After trying the DMA transfer, I'm getting this register log: With physical addresses of data = 0x059a8000 table = 0x059ac000 and the descriptor table built as: table[0] = 0x007ffe48 table[1] = 0x059a8000 table[2] = 0xc0000020 table[3] = 0x00000000 data[0] = 0x000000a0 data[1] = 0x22222222 data[2] = 0x000000a0 data[3] = 0x22222222 data[4] = 0x000000a0 data[5] = 0x22222222 data[6] = 0x0000006d data[7] = 0x00000000 BUS_CNTL = 0x7b3fa011 SRC_CNTL = 0x00000f00 PAT_REG0 = 0x11111111 GUI_CMDFIFO_DEBUG = 0x0026004c GUI_CMDFIFO_DATA = 0x00000003 FIFO_STAT = 0x00000000 BM_FRAME_BUF_OFFSET = 0x007ffe48 BM_SYSTEM_MEM_ADDR = 0x059a8000 BM_COMMAND = 0xc0000020 BM_STATUS = 0x1b0860ca BM_SYSTEM_TABLE = 0xff15bf82 BM_HOSTDATA = 0x00000000 BM_ADDR/BM_DATA = 0x00000000 BM_GUI_TABLE = 0x059ac010 BM_GUI_TABLE_CMD = 0x00000000 So, it seems that BM_SYSTEM_MEM_ADDR is pointing to our "data" address. I suppose this is right, isn't it? On the other hand, BM_GUI_TABLE is pointing one descriptor after the one we are programming, could be it's incremented everytime a descriptor is read. Could be? BM_COMMAND is right: is the command we are sending. BM_FRAME_BUF_OFFSET is just the APERTURE_OFFSET (0x7ff800) plus MACH64_BM_ADDR (0x648), this is a dogma for me. So, it seems that the descriptor is read by the card, but not interpreted. What should we expect in BM_GUI_TABLE_CMD, the same value than BM_GUI_TABLE? Could someone with insights in the RagePro function explains how and when is the DMA performed by the card? It seems that the DMA burst never takes place, but, anyway, the BM_GUI_TABLE is pointing to the supposed next descriptor. What should we expect in BM_HOSTDATA and BM_ADDR/BM_DATA ? And, finally, could someone explain what the bits in the BM_STATUS register are supposed to mean ? I think that nobody else is throwing the DMA transfer because PAT_REG0 is never updated. Could be that we are writing and reading wrong the MMIO registers? I don't think so because, for example, the BusMaster registers are not written by us directly but are showing the right value. BTW, my computer is not hanging when making this tests. I'm able to start an Xserver without DRI support after the test and write this mail. ;-) Best regards. -- Manuel Teira |
From: <AKa...@t-...> - 2001-07-31 17:30:10
|
man...@so... wrote: > > Hello again. I'd like to summarize the results I'm getting and to compare > then with you, people testing the mach64 DRI pre-alpha driver, regarding > DMA > setup. > > The last modification I've made is: > MACH64_WRITE( MACH64_BUS_CNTL, > MACH64_READ( MACH64_BUS_CNTL ) | > > MACH64_BUS_EXT_REG_EN > ); I got the same value for bus_cntl by doing this. If you want the full decryption of the bus_cntl then you have to look at atiregs.h in programs/Xserver/hw/xfree86/drivers/ati After my latest "research" I claim the bus_cntl to be the reason for the fault. Some of the flags described there are self-explaning but others I can only guess their meaning or don't know exactly what they do. > GUI_CMDFIFO_DEBUG = 0x0026004c > GUI_CMDFIFO_DATA = 0x00000003 > FIFO_STAT = 0x00000000 I get this values too (cmdfifo_data and fifo_stat exacly the same, debug as well ending with 4c). Can somebody with the docs can post the meaning flags for GUI_CMDFIFO_DEBUG/DATA? I think that could give us a hint what's wrong there. > So, it seems that BM_SYSTEM_MEM_ADDR is pointing to our "data" address. I > suppose this is right, isn't it? > On the other hand, BM_GUI_TABLE is pointing one descriptor after the one we > are programming, could be it's incremented everytime a descriptor is read. > Could be? Yes, I do think so. I've tested it with working 0x900 command for src_cntl an two descriptors. Both reads from the card where performed and the gui_table points to 0x20 after that. > BM_COMMAND is right: is the command we are sending. > BM_FRAME_BUF_OFFSET is just the APERTURE_OFFSET (0x7ff800) plus > MACH64_BM_ADDR (0x648), this is a dogma for me. > > So, it seems that the descriptor is read by the card, but not interpreted. > What should we expect in BM_GUI_TABLE_CMD, the same value than > BM_GUI_TABLE? I found out that when I manually post a command to BM_GUI_TABLE_CMD the command is directly piped to BM_GUI_TABLE and a read of GUI_TABLE_CMD afterwards returns 0x0. > Could someone with insights in the RagePro function explains how and when > is > the DMA performed by the card? It seems that the DMA burst never takes > place, > but, anyway, the BM_GUI_TABLE is pointing to the supposed next descriptor. > > What should we expect in BM_HOSTDATA and BM_ADDR/BM_DATA ? > > And, finally, could someone explain what the bits in the BM_STATUS register > are supposed to mean ? > > I think that nobody else is throwing the DMA transfer because PAT_REG0 is > never updated. > > Could be that we are writing and reading wrong the MMIO registers? I don't > think so because, for example, the BusMaster registers are not written by > us > directly but are showing the right value. My guess is that there is something *locked*. Because of the fact that reading regs and frames form the card to the memory are performed in this way. But writing to the card not. As you mentioned the gui_table is icremented but. I think this indicates that the engine is trying to perform the transfer but isn't successfull and remaining in an retry loop. > BTW, my computer is not hanging when making this tests. I'm able to start > an > Xserver without DRI support after the test and write this mail. ;-) My Xserver starts despite of the idle thing. But I cannot switch back to console. Trying this the screen get corrupted and the machine doesn't answer to the keyboard. The only clean option I have then is shutting down the machine via LAN and ssh (yes I enabled remote root login for development purpose ;-). Well I'm now a point where I cannot gather more information out of the sources. It is really frustrating to guess around, manipulate the code without any background knowledge and having to reboot the system after every test because of the failure. I don't want to resign, but if there isn't provided any further information I haven't any hope that there will be any progress. Perhaps somebody knows somebody who knows a public off-shore ftp-site with mach64 programmer's guide and/or the the sdk ... -Andreas Karrenbauer |
From: Manuel T. <man...@so...> - 2001-08-04 18:26:43
|
El Martes 31 Julio 2001 18:25, Andreas Karrenbauer escribió: > I found out that when I manually post a command to BM_GUI_TABLE_CMD the > command is directly piped to BM_GUI_TABLE and a read of GUI_TABLE_CMD > afterwards returns 0x0. That's interesting. Perhaps the BM_GUI_TABLE_CMD is a write-only register or something so? Frank, could you help us about this? > > My guess is that there is something *locked*. Because of the fact that > reading regs and frames form the card to the memory are performed in > this way. But writing to the card not. As you mentioned the gui_table is > icremented but. I think this indicates that the engine is trying to > perform the transfer but isn't successfull and remaining in an retry > loop. > Yes, but I think we're making the same things than the working Utah-GLX driver. I'm thinking about installing a cut-out version of the X 3.3.6 with the glx driver, to look deeper in the card setup. This way, I'll have three X versions: my distro one (4.0.3) the testing one (4.1.0) and the 3.3.6. > > Well I'm now a point where I cannot gather more information out of the > sources. It is really frustrating to guess around, manipulate the code > without any background knowledge and having to reboot the system after > every test because of the failure. I don't want to resign, but if there > isn't provided any further information I haven't any hope that there > will be any progress. I'm sure there must be a difference between the GLX driver and the DRI one that's driving us mad. I expect that the privileged people that have the docs could help us. Frank Earl has commented lately about a difference in the bus-mastering procedure between DRI and Utah-GLX, regarding the aperture being used. BTW, Have you tried to get the documents from ATI ? I've got no answer from them the last tries I've made. > > Perhaps somebody knows somebody who knows a public off-shore ftp-site > with mach64 programmer's guide and/or the the sdk ... I've been looking for these kind of docs for a while, but no luck. Best regards. -- Manuel Teira |
From: Carl B. <afn...@af...> - 2001-08-05 02:16:50
|
ATI... I emailed them asking for the docs about 2 months ago. no answer. Manuel Teira wrote: >El Martes 31 Julio 2001 18:25, Andreas Karrenbauer escribió: > >>I found out that when I manually post a command to BM_GUI_TABLE_CMD the >>command is directly piped to BM_GUI_TABLE and a read of GUI_TABLE_CMD >>afterwards returns 0x0. >> > >That's interesting. Perhaps the BM_GUI_TABLE_CMD is a write-only register or >something so? Frank, could you help us about this? > >>My guess is that there is something *locked*. Because of the fact that >>reading regs and frames form the card to the memory are performed in >>this way. But writing to the card not. As you mentioned the gui_table is >>icremented but. I think this indicates that the engine is trying to >>perform the transfer but isn't successfull and remaining in an retry >>loop. >> > >Yes, but I think we're making the same things than the working Utah-GLX >driver. I'm thinking about installing a cut-out version of the X 3.3.6 with >the glx driver, to look deeper in the card setup. This way, I'll have three X >versions: my distro one (4.0.3) the testing one (4.1.0) and the 3.3.6. > >>Well I'm now a point where I cannot gather more information out of the >>sources. It is really frustrating to guess around, manipulate the code >>without any background knowledge and having to reboot the system after >>every test because of the failure. I don't want to resign, but if there >>isn't provided any further information I haven't any hope that there >>will be any progress. >> > >I'm sure there must be a difference between the GLX driver and the DRI one >that's driving us mad. I expect that the privileged people that have the docs >could help us. Frank Earl has commented lately about a difference in the >bus-mastering procedure between DRI and Utah-GLX, regarding the aperture >being used. > >BTW, Have you tried to get the documents from ATI ? I've got no answer from >them the last tries I've made. > >>Perhaps somebody knows somebody who knows a public off-shore ftp-site >>with mach64 programmer's guide and/or the the sdk ... >> > >I've been looking for these kind of docs for a while, but no luck. > >Best regards. > >-- >Manuel Teira > >_______________________________________________ >Dri-devel mailing list >Dri...@li... >http://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Mike A. H. <mh...@re...> - 2001-08-06 16:23:07
|
On Sat, 4 Aug 2001, Carl Busjahn wrote: >ATI... I emailed them asking for the docs about 2 months ago. no answer. Go to the ATI website and sign up to become a registered developer. ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: xfr...@re... IRC: #redhat-xfree86 on irc.openprojects.org ---------------------------------------------------------------------- |
From: Manuel T. <man...@so...> - 2001-08-08 16:14:15
|
El Lunes 06 Agosto 2001 18:23, Mike A. Harris escribió: > On Sat, 4 Aug 2001, Carl Busjahn wrote: > >ATI... I emailed them asking for the docs about 2 months ago. no answer. > > Go to the ATI website and sign up to become a registered > developer. That's what I've made. The first time they rejected my petition, the next times I tried (with pretended names also to check if I could be in some kind of black list ;-) ), I got no response from them. -- M. Teira |