From: Michael <le...@nt...> - 2002-04-27 17:38:19
|
On Sat, Apr 27, 2002 at 06:01:14PM +0100, José Fonseca wrote: > Why do you say virt_to_bus is deprecated? Where can I find more > information about these APIs? /usr/src/linux/Documentaion/IO-mapping.txt (right at the top) and DMA-mapping.txt -- Michael. |
From: Benjamin H. <be...@ke...> - 2002-04-27 20:36:28
|
>> thread). On some PPC's like PReP, the mapping between bus addresses >> and CPU physical addresses on PCI isn't 1:1 and the system RAM is >> not mapped at 0 for bus mastering PCI devices. If you use the PCI >> DMA API, things are ok. If you aren't, then some tweaks may be needed. >> (See the definition of deprecated virt_to_bus in asm-ppc/io.h) > >The DRM doesn't use the PCI DMA API. Instead does everything manually. > >Why do you say virt_to_bus is deprecated? Where can I find more >information about these APIs? Kernel's Documentation/DMA-mapping.txt is your friend ;) Though virt_to_bus should still work, at least on PReP. Beware of 2 things that can happen on non-x86 archs: - The PCI BAR values can't be used directly for ioremap, use the pci resources provided by the kernel PCI layer, those may have been "fixed up" in cases where the CPU->PCI space isn't 1:1 physically. But I don't think this is your problem. - The RAM may not be at 0 from PCI view, but in those cases, either the PCI DMA APIs or virt_to_bus should do the right thing. Though, as Leif pointed out, it's a Mac, so none of the above issues should matter, except if you are trying to tap the card's VGA IOs, but that's a different story. As far as UniNorth (yet, all AGP macs have the uninorth chipset) is concerned, the only working version so far is the one in my rsync kernel tree, I never merged it upstream as it requires a few hacks to the DRM and I never manage to have it stable (not the uninorth code itself, which is pretty trivial, but for some reasons, both r128's and Radeon's exhibit occasionnal lockups when used with AGP on Mac with UniNorth chipset. I've tried all sort of things, like reading the chip's ring write ptr instead of relying on the one written to memory, adding delay's, etc... but so far had no success). Ben. |
From: Peter A. <pe...@da...> - 2002-04-27 17:34:02
|
> > >What PPC machine is this ? (sorry, I missed the beginning of the >thread). > I am using an ibook "blueberry" with a 300mhz powerpc processor and ATI rage 3D mobility 2X agp graphics board with 4mb of ram. Peter |
From: Leif D. <lde...@re...> - 2002-04-27 16:31:15
|
On 27 Apr 2002, Michel D=E4nzer wrote: > On Sat, 2002-04-27 at 09:50, Jos=E9 Fonseca wrote: > > On 2002.04.26 12:42 Michel D=E4nzer wrote: > > > On Fri, 2002-04-26 at 00:41, Peter Andersson wrote: > > > > > > > > I tried the backtrace option but it only produced a bunch of numb= ers > > > and > > > > letters, and since i am not exactly sure if i am able to read the= m > > > right > > > > i don=B4t think they are useful for anyone, but if you want me to= give it > > > > a try please let me know. > > >=20 > > > If you provide the System.map corresponding to the kernel to yaboot= , > > > xmon will show symbol names. This is my default yaboot label: > > >=20 > > > image=3D/vmlinux > > > label=3DDebian > > > sysmap=3D/System.map > > >=20 > >=20 > > Peter, could you try this so that we could pin point where the fault=20 > > occurred exactly. I don't know if it's needed to recompile the kernel= to=20 > > have more symbol information. On the x86 there is a specific option f= or=20 > > that in the kernel configuration. >=20 > That's not necessary for xmon. >=20 > > In the mean while I'll try look at the last kmsg debug statements to = see=20 > > if I found any further clue. >=20 > Isn't it the buglet Leif fixed tonight? I changed virt_to_phys to virt_to_bus like you suggested, but that's in the _dispatch_vertex. In the system log that Peter posted, the last message before the _vm_dma_nopage was _dispatch_clear, which is currently a _wait_for_fifo followed by a series of MMIO writes. Peter, if you set=20 MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a= =20 debug statement for each register access. This could help us find the=20 problem. That being said though, I don't see where the _vm_dma_nopage=20 comes in between _dispatch_clear and the missing debug statement from=20 _dma_vertex. BTW, since I checked in my changes, I've been having problems with the PC= I path again. Jose, I did most of my testing before merging your changes t= o the vertex buffer private struct (for aging), but I don't really see why that would cause a problem. I thought I had tested this after I updated, but it's possible that I forgot to remove agpgart or something. I think this would be easier to deal with if the PCI path used the new PCI DMA interface like I'm doing with the descriptor table, so we wouldn't have t= o use the deprecated virt_to_bus. From what I can see, the buf->address basically comes from __get_free_pages which is called by DRM(alloc_pages). When we get the MMIO path working for ppc, I think we'll still have to=20 make some changes for DMA. When filling the vertex buffers and setting u= p=20 the descriptor tables, won't we have to convert to little-endian? --=20 Leif Delgass=20 http://www.retinalburn.net |
From: José F. <j_r...@ya...> - 2002-04-27 17:11:14
|
On 2002.04.27 17:31 Leif Delgass wrote: > On 27 Apr 2002, Michel Dänzer wrote: > > ... > > > > Isn't it the buglet Leif fixed tonight? > > I changed virt_to_phys to virt_to_bus like you suggested, but that's in > the _dispatch_vertex. In the system log that Peter posted, the last > message before the _vm_dma_nopage was _dispatch_clear, which is currently > a _wait_for_fifo followed by a series of MMIO writes. Peter, if you set > MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a > debug statement for each register access. This could help us find the > problem. That being said though, I don't see where the _vm_dma_nopage > comes in between _dispatch_clear and the missing debug statement from > _dma_vertex. I don't think does. I think that it's called by the kernel, as a response to a page fault. > > BTW, since I checked in my changes, I've been having problems with the > PCI > path again. Jose, I did most of my testing before merging your changes > to > the vertex buffer private struct (for aging), but I don't really see why > that would cause a problem. I thought I had tested this after I updated, I'll check it. > but it's possible that I forgot to remove agpgart or something. I think > this would be easier to deal with if the PCI path used the new PCI DMA > interface like I'm doing with the descriptor table, so we wouldn't have > to Yep. Doesn't make much sense to do something that is already done by the remaining kernel. Further, I don't see why the DRM should give the AGP/PCI buffers details to the X server. AFAIK this information is only used to call the DRM(dma_init), so why make it go back and forward, creating unnecessary complexity? > use the deprecated virt_to_bus. From what I can see, the buf->address > basically comes from __get_free_pages which is called by > DRM(alloc_pages). > > When we get the MMIO path working for ppc, I think we'll still have to > make some changes for DMA. When filling the vertex buffers and setting > up the descriptor tables, won't we have to convert to little-endian? Most probably. José Fonseca |
From: Michel <mi...@da...> - 2002-04-27 20:59:49
|
On Sat, 2002-04-27 at 18:31, Leif Delgass wrote: >=20 > When we get the MMIO path working for ppc, I think we'll still have to=20 > make some changes for DMA. When filling the vertex buffers and setting u= p=20 > the descriptor tables, won't we have to convert to little-endian? Yes, unless the chip can byte-swap this stuff, but I doubt it as not even the Rage128 can, only the Radeon. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Leif D. <lde...@re...> - 2002-04-27 22:00:31
|
On 27 Apr 2002, Michel D=E4nzer wrote: > On Sat, 2002-04-27 at 18:31, Leif Delgass wrote: > >=20 > > When we get the MMIO path working for ppc, I think we'll still have t= o=20 > > make some changes for DMA. When filling the vertex buffers and setti= ng up=20 > > the descriptor tables, won't we have to convert to little-endian? >=20 > Yes, unless the chip can byte-swap this stuff, but I doubt it as not > even the Rage128 can, only the Radeon. I see that Rage128 swaps all writes to the ring buffer, but why doesn't i= t=20 also need to swap data when filling the vertex buffers in the Mesa driver= ? Looking at the mach64 utah-glx driver, it swaps both the register addresses (which have been converted to dword offsets) and data that go into the vertex buffer. For pseudo DMA, it converts back to big-endian when reading the register offsets from the buffer before converting them back to byte offsets. --=20 Leif Delgass=20 http://www.retinalburn.net |
From: Michel <mi...@da...> - 2002-04-27 22:28:30
Attachments:
r128-dri.diff
|
On Sun, 2002-04-28 at 00:00, Leif Delgass wrote: > On 27 Apr 2002, Michel D=E4nzer wrote: >=20 > > On Sat, 2002-04-27 at 18:31, Leif Delgass wrote: > > >=20 > > > When we get the MMIO path working for ppc, I think we'll still have t= o=20 > > > make some changes for DMA. When filling the vertex buffers and setti= ng up=20 > > > the descriptor tables, won't we have to convert to little-endian? > >=20 > > Yes, unless the chip can byte-swap this stuff, but I doubt it as not > > even the Rage128 can, only the Radeon. >=20 > I see that Rage128 swaps all writes to the ring buffer, but why doesn't i= t=20 > also need to swap data when filling the vertex buffers in the Mesa driver= ? It would have to. The r128 driver got broken on big endian by the update to Mesa 3.5/4.x. I hadn't gotten around to fixing it and now I sold my old PowerBook, but the basic fix is attached. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Peter A. <pe...@da...> - 2002-04-28 02:15:30
Attachments:
kmsg.txt
System_log.txt
|
> > >Peter, if you set >MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a >debug statement for each register access. This could help us find the >problem. That being said though, I don't see where the _vm_dma_nopage >comes in between _dispatch_clear and the missing debug statement from >_dma_vertex. > The system log is attatched to this email, and i hope it will make you happy since there are an kernel oops included. I also took the oppurtunity to make a new "kmsg trace" which is different than the old one, hope you can make something out of it. Regards Peter |
From: Leif D. <lde...@re...> - 2002-04-28 05:07:56
|
On Sun, 28 Apr 2002, Peter Andersson wrote: > > > > > >Peter, if you set > >MACH64_VERBOSE to 1 in mach64_drv.h and rebuild the DRM, you should see a > >debug statement for each register access. This could help us find the > >problem. That being said though, I don't see where the _vm_dma_nopage > >comes in between _dispatch_clear and the missing debug statement from > >_dma_vertex. > > > The system log is attatched to this email, and i hope it will make you > happy since there are an kernel oops included. I also took the > oppurtunity to make a new "kmsg trace" which is different than the old > one, hope you can make something out of it. Thanks for the info, I know testing this can be a pain with all the reboots. :) Well, it looks like the _dispatch_clear completes without a problem. Could you run ksymoops on the syslog? That will decode the back trace from the oops (it's best to run it right after the oops before you reboot, so you use the symbol table from the modules installed at the time of the error). I just checked in changes to do byte swapping for the DMA test and the vertex buffers. The vertex buffer changes are needed for real DMA, but this won't fix your current problem with MMIO. The DMA test should work however, so if you update from cvs and this is working, that's a good start. If it works, you should see the same 7 VERTEX_ register values in the system log before and after the test. One note about this: once a DMA pass fails, you'll need to do a cold reboot before DMA will work again. -- Leif Delgass http://www.retinalburn.net |
From: Leif D. <lde...@re...> - 2002-04-28 05:13:50
|
On Sun, 28 Apr 2002, Leif Delgass wrote: > If it works, you should see the same 7 VERTEX_ register values in the > system log before and after the test. Sorry, I meant to say that you should see all zeros for the registers before the transfer and 0x11111111, 0x22222222, etc. after the transfer. -- Leif Delgass http://www.retinalburn.net |
From: Peter A. <pe...@da...> - 2002-04-28 16:06:56
|
>>> The DMA test should work however, so if you update from cvs and this is working, that's >>> a good start. >>If it works, you should see all zeros for the registers >>before the transfer and 0x11111111, 0x22222222, etc. after the transfer. >> I suppose this is what you are talking about: Apr 27 17:43:54 tsathoggua kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 Apr 27 17:43:54 tsathoggua kernel: [drm] Creating pool ... Apr 27 17:43:54 tsathoggua kernel: [drm] Allocating table memory ... Apr 27 17:43:54 tsathoggua kernel: [drm] Allocating data memory ... Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_S = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_T = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_W = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_SPEC_ARGB = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_Z = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_ARGB = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] (Before DMA Transfer) VERTEX_1_X_Y = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] Preparing table ... Apr 27 17:43:54 tsathoggua kernel: [drm] table[0] = 0x48fe7f00 Apr 27 17:43:54 tsathoggua kernel: [drm] table[1] = 0x00405f0f Apr 27 17:43:54 tsathoggua kernel: [drm] table[2] = 0x280000c0 Apr 27 17:43:54 tsathoggua kernel: [drm] table[3] = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] data[0] = 0x90010600 Apr 27 17:43:54 tsathoggua kernel: [drm] data[1] = 0x11111111 Apr 27 17:43:54 tsathoggua kernel: [drm] data[2] = 0x22222222 Apr 27 17:43:54 tsathoggua kernel: [drm] data[3] = 0x33333333 Apr 27 17:43:54 tsathoggua kernel: [drm] data[4] = 0x44444444 Apr 27 17:43:54 tsathoggua kernel: [drm] data[5] = 0x55555555 Apr 27 17:43:54 tsathoggua kernel: [drm] data[6] = 0x66666666 Apr 27 17:43:54 tsathoggua kernel: [drm] data[7] = 0x77777777 Apr 27 17:43:54 tsathoggua kernel: [drm] data[8] = 0x6d000000 Apr 27 17:43:54 tsathoggua kernel: [drm] data[9] = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] waiting for idle... Apr 27 17:43:54 tsathoggua kernel: [drm] BUS_CNTL = 0x7b3fa010 Apr 27 17:43:54 tsathoggua kernel: [drm] SRC_CNTL = 0x00000000 Apr 27 17:43:54 tsathoggua kernel: [drm] Apr 27 17:43:54 tsathoggua kernel: [drm] data = 0x0f5f4000 Apr 27 17:43:54 tsathoggua kernel: [drm] table = 0x0f5e8000 Apr 27 17:43:54 tsathoggua kernel: [drm] starting DMA transfer... Apr 27 17:43:54 tsathoggua kernel: [drm] starting DMA transfer... done. Apr 27 17:43:54 tsathoggua kernel: [drm] waiting for idle... Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_S = 0x11111111 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_T = 0x22222222 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_W = 0x33333333 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_SPEC_ARGB = 0x00444444 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_Z = 0x55550000 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_ARGB = 0x66666666 Apr 27 17:43:54 tsathoggua kernel: [drm] (After DMA Transfer) VERTEX_1_X_Y = 0x77777777 Apr 27 17:43:54 tsathoggua kernel: [drm] freeing memory. Apr 27 17:43:54 tsathoggua kernel: [drm] returning ... Apr 27 17:43:54 tsathoggua kernel: [drm] Creating pci pool Apr 27 17:43:54 tsathoggua kernel: [drm] Allocating descriptor table memory Apr 27 17:43:54 tsathoggua kernel: [drm] descriptor table: cpu address: 0xcf5e8000, phys address: 0x0f5e8000 I guess it works :-) . Peter |
From: Peter A. <pe...@da...> - 2002-04-28 11:29:13
|
> > >Thanks for the info, I know testing this can be a pain with all the >reboots. :)=20 > It=B4s no problem, and its certainly worth it when you guys get this thin= g=20 working! >Well, it looks like the _dispatch_clear completes without a >problem. Could you run ksymoops on the syslog? That will decode the ba= ck >trace from the oops (it's best to run it right after the oops before you >reboot, so you use the symbol table from the modules installed at the ti= me >of the error). =20 > It is included in this email. >I just checked in changes to do byte swapping for the DMA >test and the vertex buffers. The vertex buffer changes are needed for >real DMA, but this won't fix your current problem with MMIO. The DMA te= st >should work however, so if you update from cvs and this is working, that= 's >a good start. If it works, you should see the same 7 VERTEX_ register >values in the system log before and after the test.=20 > I am updating right now and will get back to you as soon as the=20 compilation finishes. Peter |
From: Peter A. <pe...@da...> - 2002-04-27 12:48:42
|
> Peter, could you try this so that we could pin point where the fault=20 > occurred exactly. I don't know if it's needed to recompile the kernel=20 > to have more symbol information. On the x86 there is a specific option=20 > for that in the kernel configuration. > Sorry i can=B4t be of more help, but it seems that many of the "error=20 codes" are not included in the sytem map i get 21 error codes when=20 backtracing but only two of them are in plain text, those are c000431c T ret_from_syscall_1+0x0 exception:cc00 [cd17ff50] fd14868 And i have checked that the System.map gets loaded since if I remove=20 from the path specified in yaboot.conf it i can=B4t boot. Peter |