[Dri-devel] Mach64: Questions about locking
Hello. I was investigating on how to allow both 2D and 3D acceleration in the Mach64. So I'm a little confused: First of all, I looked at the R128 and RADEON drivers and they are only doing a DRILock/DRIUnlock in the LeaveVT and EnterVT functions. Does this mean that those cards can do 3D and 2D operation at the same time? Then I looked a little in the mga 2D driver and a few more locking operations are showed. After this, I'm not sure about what we must interlock between 2D and 3D operation. I would like to know what do you think about the following assumptions: 1.-The proper function to lock 3D operation from XFree is DRILock. 2.-We must lock all the operations in the 2D driver that tries: Mach64WaitForIdle Mach64WaitForFIFO to guarantee that the reached FIFO condition is true. This investigation shows me another funny thing: When the 2D Xfree driver only has to make one register write, it doesn't try a Mach64WaitForFIFO. Is this correct? If the DRI driver was writing on the command FIFO, couldn't the 2D attempt to write on the FIFO fail ? On the other hand, when there are more than one register write, say N-register writes, the 2D driver makes a Mach64WaitForFIFO(N) before trying to write to the registers. Is there any other 2D operation that we should need to lock? What criteria must I follow to make this the right way? I suppose that I don't need to lock any register write, but I'm not sure, because the FIFO could get full while I'm writing from the 2D driver. I will keep looking to the other drivers, but I would like to have others opinions. On the MESA side, it looks that the hardware locking is already implemented through the functions LOCK_HARDWARE and UNLOCK_HARDWARE. Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Questions about locking
I haven't done an extensive look at this, but I've noticed a couple of things. The 2D driver seems to use a caching scheme for register writes. Also, at one point I had a nasty lockup trying to switch to a vt from fullscreen quake, but I haven't tried it with my latest build yet. I've noticed other drivers have a fullscreen ioctl, but the mach64 currently does not. It seems that once we have the DMA interface defined, we'll want the 2D acceleration to use that as well as the locking scheme, right? Frank, any progress there? On another note, I'm attaching a small patch to fix a few things. 1. The AGP register setup was using the wrong macro, since the registers are in Block 1, it should be using outm() instead of outr(). 2. I added some defines for the FIFO sizes in GUI_CNTL and moved the setup to do_dma_init instead of the busmaster test. 3. I did some general cleanup to fix a couple typos and quiet compiler warnings. 4. The DMA memory allocation used in the busmaster test uses the interface described in the kernel docs (Documentation/DMA-mapping.txt). The 2.4.13 kernel adds 64-bit DMA support, so if you have CONFIG_HIGHMEM defined, dma_addr_t is defined as u64. The code was passing u32 handles to the allocation/free functions instead of dma_addr_t handles. This bit me as I have CONFIG_HIGHMEM4G/CONFIG_HIGHMEM set for some reason (wishful thinking?). I changed this and cast the returned handles to u32 to get addresses to pass to the card. I think this is OK, since 32-bit DMA is assumed unless you use pci_set_dma_mask to indicate that the device can do 64-bit. 5. You can ignore the changes in host.def, my .cvsignore wasn't working for some reason. Let me know if you see any problems with the patch and I'll try to take a look at the locking issues, but I think we need Frank's input there too. --Leif On Fri, 26 Oct 2001, Manuel Teira wrote: Hello. I was investigating on how to allow both 2D and 3D acceleration in the Mach64. So I'm a little confused: First of all, I looked at the R128 and RADEON drivers and they are only doing a DRILock/DRIUnlock in the LeaveVT and EnterVT functions. Does this mean that those cards can do 3D and 2D operation at the same time? Then I looked a little in the mga 2D driver and a few more locking operations are showed. After this, I'm not sure about what we must interlock between 2D and 3D operation. I would like to know what do you think about the following assumptions: 1.-The proper function to lock 3D operation from XFree is DRILock. 2.-We must lock all the operations in the 2D driver that tries: Mach64WaitForIdle Mach64WaitForFIFO to guarantee that the reached FIFO condition is true. This investigation shows me another funny thing: When the 2D Xfree driver only has to make one register write, it doesn't try a Mach64WaitForFIFO. Is this correct? If the DRI driver was writing on the command FIFO, couldn't the 2D attempt to write on the FIFO fail ? On the other hand, when there are more than one register write, say N-register writes, the 2D driver makes a Mach64WaitForFIFO(N) before trying to write to the registers. Is there any other 2D operation that we should need to lock? What criteria must I follow to make this the right way? I suppose that I don't need to lock any register write, but I'm not sure, because the FIFO could get full while I'm writing from the 2D driver. I will keep looking to the other drivers, but I would like to have others opinions. On the MESA side, it looks that the hardware locking is already implemented through the functions LOCK_HARDWARE and UNLOCK_HARDWARE. Best regards. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass ? exports ? mach64-patch ? config/cf/.cvsignore Index: config/cf/host.def === RCS file: /cvsroot/dri/xc/xc/config/cf/host.def,v retrieving revision 1.29 diff -u -r1.29 host.def --- config/cf/host.def 2001/08/27 17:43:00 1.29 +++ config/cf/host.def 2001/10/26 18:16:56 @@ -28,7 +28,7 @@ #define BuildXF86DRI YES -#define HasGlide3 YES +#define HasGlide3 NO /* To do profiling of the dynamically loaded 'xyz_dri.so' object, turn * this on. @@ -50,10 +50,10 @@ /* #define DoLoadableServer NO */ /* Optionally turn this on to change the place where you install the build */ -/* #define ProjectRoot /usr/X11R6-DRI */ +#define ProjectRoot /usr/X11R6-DRI /* Optionally turn this on to force the kernel modules to build */ -/* #define BuildXF86DRM YES */ +#define BuildXF86DRM YES #define XF86AFB NO Index: programs/Xserver/hw/xfree86/drivers/ati/atidri.c === RCS file:
Re: [Dri-devel] Mach64: Questions about locking
El Vie 26 Oct 2001 20:21, Leif Delgass escribió: I haven't done an extensive look at this, but I've noticed a couple of things. The 2D driver seems to use a caching scheme for register writes. Also, at one point I had a nasty lockup trying to switch to a vt from fullscreen quake, but I haven't tried it with my latest build yet. I've noticed other drivers have a fullscreen ioctl, but the mach64 currently does not. It seems that once we have the DMA interface defined, we'll want the 2D acceleration to use that as well as the locking scheme, right? Frank, any progress there? I have been looking to the register caching. I don't know if this caching has sense once the DRI is also writing directly to some of the registers. I saw seldom times this in my XFree log file: .. $REGISTER_NAME write cache disabled! this is written by the Mach64Sync function, that compares all the cached register values with the actual values ( and shows that error when values differ). I commented out the register caching when trying to find the DMA problem (it's still commented out in the branch code). I've also noticed that the other drivers (RADEON , R128) don't use the caching 'feature'. I've also seen the outm/inm outf macros (atimach64io.h). These are the ones that provides the cache features. I wonder if we should block the hardware for any of these macros (to guarantee that the FIFO entries are true). Anyway, I think that there are still race conditions, because this kind of code: ... ATIMach64WaitForFIFO(pATI, 6); outf(SRC_OFF_PITCH, pATIHW-src_off_pitch); outf(SRC_Y_X, SetWord(pATIHW-src_x, 1) | SetWord(pATIHW-src_y, 0)); outf(SRC_HEIGHT1_WIDTH1, SetWord(pATIHW-src_width1, 1) | SetWord(pATIHW-src_height1, 0)); outf(SRC_Y_X_START, SetWord(pATIHW-src_x_start, 1) | SetWord(pATIHW-src_y_start, 0)); outf(SRC_HEIGHT2_WIDTH2, SetWord(pATIHW-src_width2, 1) | SetWord(pATIHW-src_height2, 0)); outf(SRC_CNTL, pATIHW-src_cntl); ... If we only block the ouf macros and the WaitForFIFO macro separately, we cannot guarantee that there will be 6 free slots once the WaitForFIFO has finished (because of the DRM). So, what I think we should do is: 1.- Block all the code that matches the previous template (mainly in atimach64.c) , in this way: DRILock( pScreenInfo-pScreen ); ATIMach64WaitForFIFO( pATI, n ); /* * Here the outf stuff */ DRIUnlock( pScreenInfo-pScreen ); 2.-Disable the Register Caching for all the registers. Perhaps we could later enable the caching for the registers that are not used by the drm driver. Talking about the Q3 hang when switching vts: I don't know if this is the problem, but the other drivers (RADEON, R128) has a DRILock (DRIUnlock) calls when doing enterVT (leaveVT), that mach64 hasn't. I will try to test this behaviour today (once I have Q3 installed ;-) ). On another note, I'm attaching a small patch to fix a few things. 1. The AGP register setup was using the wrong macro, since the registers are in Block 1, it should be using outm() instead of outr(). 2. I added some defines for the FIFO sizes in GUI_CNTL and moved the setup to do_dma_init instead of the busmaster test. 3. I did some general cleanup to fix a couple typos and quiet compiler warnings. 4. The DMA memory allocation used in the busmaster test uses the interface described in the kernel docs (Documentation/DMA-mapping.txt). The 2.4.13 kernel adds 64-bit DMA support, so if you have CONFIG_HIGHMEM defined, dma_addr_t is defined as u64. The code was passing u32 handles to the allocation/free functions instead of dma_addr_t handles. This bit me as I have CONFIG_HIGHMEM4G/CONFIG_HIGHMEM set for some reason (wishful thinking?). I changed this and cast the returned handles to u32 to get addresses to pass to the card. I think this is OK, since 32-bit DMA is assumed unless you use pci_set_dma_mask to indicate that the device can do 64-bit. 5. You can ignore the changes in host.def, my .cvsignore wasn't working for some reason. Let me know if you see any problems with the patch and I'll try to take a look at the locking issues, but I think we need Frank's input there too. At a first glance, it looks fine. I will apply it to the branch once that I see that works fine on my machine. -- Manuel Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Questions about locking
On Fri, 26 Oct 2001, Manuel Teira wrote: I have been looking to the register caching. I don't know if this caching has sense once the DRI is also writing directly to some of the registers. I saw seldom times this in my XFree log file: .. $REGISTER_NAME write cache disabled! I've noticed that too. this is written by the Mach64Sync function, that compares all the cached register values with the actual values ( and shows that error when values differ). I commented out the register caching when trying to find the DMA problem (it's still commented out in the branch code). I've also noticed that the other drivers (RADEON , R128) don't use the caching 'feature'. I've also seen the outm/inm outf macros (atimach64io.h). These are the ones that provides the cache features. I wonder if we should block the hardware for any of these macros (to guarantee that the FIFO entries are true). Anyway, I think that there are still race conditions, because this kind of code: ... ATIMach64WaitForFIFO(pATI, 6); outf(SRC_OFF_PITCH, pATIHW-src_off_pitch); outf(SRC_Y_X, SetWord(pATIHW-src_x, 1) | SetWord(pATIHW-src_y, 0)); outf(SRC_HEIGHT1_WIDTH1, SetWord(pATIHW-src_width1, 1) | SetWord(pATIHW-src_height1, 0)); outf(SRC_Y_X_START, SetWord(pATIHW-src_x_start, 1) | SetWord(pATIHW-src_y_start, 0)); outf(SRC_HEIGHT2_WIDTH2, SetWord(pATIHW-src_width2, 1) | SetWord(pATIHW-src_height2, 0)); outf(SRC_CNTL, pATIHW-src_cntl); ... If we only block the ouf macros and the WaitForFIFO macro separately, we cannot guarantee that there will be 6 free slots once the WaitForFIFO has finished (because of the DRM). So, what I think we should do is: 1.- Block all the code that matches the previous template (mainly in atimach64.c) , in this way: DRILock( pScreenInfo-pScreen ); ATIMach64WaitForFIFO( pATI, n ); /* * Here the outf stuff */ DRIUnlock( pScreenInfo-pScreen ); 2.-Disable the Register Caching for all the registers. Perhaps we could later enable the caching for the registers that are not used by the drm driver. Sounds reasonable. I guess this is the function of the CCE stuff in the r128 driver (although that seems to be a hardware feature, it loads microcode at initialization)? Talking about the Q3 hang when switching vts: I don't know if this is the problem, but the other drivers (RADEON, R128) has a DRILock (DRIUnlock) calls when doing enterVT (leaveVT), that mach64 hasn't. I will try to test this behaviour today (once I have Q3 installed ;-) ). On another note, I'm attaching a small patch to fix a few things. [snip] At a first glance, it looks fine. I will apply it to the branch once that I see that works fine on my machine. Actually, the stuff in AGPInit should probably be disabled (just move the #endif back to the end before the return) for now since it seems to cause texture corruption. Once we get the driver actually using AGP then we can enable it. -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
El Mié 17 Oct 2001 11:44, R C escribió: On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote: Regarding theories on DMA and Mach64 and XFree 4.10: I just finished a module that uses the System DMA unit for video capture transfers, and it works fine under a (highly hacked) XFree 4.1.0 server. System: Dual 550 Celeron, All-in-Wonder (original) PCI, 3D Rage II+. XServer is 4.1.0 with Gatos devel branch. Module is for 2.4 kernel. To use this on another card, you would have to enter the proper PCI id in the code. Oh yes, it uses the secondary register aperture, not the linear mapped aperture, but I don't think it makes a difference. Have not tried GUI dma, but it is quite similar. R C I'm sorry, but have no luck trying to install your module. It always bugs me with errors: These ones: #insmod ati_dma.o Oct 18 22:23:49 localhost kernel: PCI: Sharing IRQ 11 with 00:02.0 Oct 18 22:23:49 localhost kernel: PCI: Sharing IRQ 11 with 00:05.0 Oct 18 22:23:49 localhost kernel: Found ATI card at 0xf500. Oct 18 22:23:49 localhost kernel: PCI: Unable to reserve mem region #1:100@f500 for device 01:00.0 Oct 18 22:23:49 localhost kernel: Could not request IO regions! # Or these other ones: #insmod ati_dma.o Oct 18 22:23:51 localhost kernel: PCI: Found IRQ 11 for device 01:00.0 Oct 18 22:23:51 localhost kernel: PCI: Sharing IRQ 11 with 00:02.0 Oct 18 22:23:51 localhost kernel: PCI: Sharing IRQ 11 with 00:05.0 Oct 18 22:23:51 localhost kernel: Found ATI card at 0xf500. Oct 18 22:23:51 localhost kernel: Cannot reserve interrupt: 11 for ATI card! # I don't know what is happening (and many other things). Any idea? ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote:
Regarding theories on DMA and Mach64 and XFree 4.10:
I just finished a module that uses the System DMA unit for video capture
transfers, and it works fine under a (highly hacked) XFree 4.1.0 server.
System: Dual 550 Celeron, All-in-Wonder (original) PCI, 3D Rage II+.
XServer is 4.1.0 with Gatos devel branch. Module is for 2.4 kernel. To use
this on another card, you would have to enter the proper PCI id in the
code. Oh yes, it uses the secondary register aperture, not the linear
mapped aperture, but I don't think it makes a difference.
Have not tried GUI dma, but it is quite similar.
R C
--
They said it was *daft* to build a space station in a swamp, but I showed them!
It sank unto the swamp. So I built a second space station. That sank into
the swamp too. My third space station sank into the swamp. So I built a fourth
one. That fell into a time warp and _then_ sank into the swamp. But the fifth
one... stayed up! --Monty Python/Babylon 5
#include linux/module.h
#include linux/pci.h
#include linux/init.h
#include linux/pci_ids.h
#include linux/compatmac.h
#include linux/devfs_fs_kernel.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/mm.h
#include linux/slab.h
#include asm/processor.h
#include asm-i386/io.h
/*#include linux/version.h
#include linux/kernel.h
#include linux/module.h
#include linux/fs.h
#include linux/kernel.h
#include linux/major.h
#include linux/malloc.h
#include linux/mm.h
#include linux/poll.h
#include linux/pci.h
#include linux/signal.h
#include linux/ioport.h
#include asm/pgtable.h
#include asm/page.h
#include linux/sched.h
#include asm/segment.h
#include linux/types.h
#include linux/wrapper.h
#include linux/kmod.h
#include linux/vmalloc.h
#include linux/init.h*/
/*
1. Find the device. call pci_register_driver()
2. Enable devices: pci_enable_device()
Call pci_set_master() to enable bus master.
A field, by default, is 640x240x2 (307200). This corresponds
to exactly 75 pages when they are 4K sized (AFAIK the minimum page size).
The main restriction is that they must be 4K aligned.
*/
#define SUCCESS 0
#define MAJOR_NUM 240
#define DEVICE_NAME atidma
//#define DEBUG 1
#define CAP_INT_CNTL0x908
#define CAP_INT_STATUS 0x90C
#define RADEON_CAP0_VBI0_OFFSET 0x093C
#define RADEON_CAP0_VBI1_OFFSET 0x0940
#define RADEON_CAP0_VBI_V_WINDOW 0x0944
#define RADEON_CAP0_VBI_H_WINDOW 0x0948
#define RADEON_CAP0_CONFIG0x0958
#define regw(a,b) *(MMR+a)=b
#define regr(a) *(MMR+a)
#define MEM_BASE 0x0248
#define BUS_CNTL 0x28+(256)
#define CRTC_INT_CNTL 0x06+(256)
#define BM_SYSTEM_TABLE 0x6F
#define CAPTURE_BUF0_OFFSET 0x20
#define CAPTURE_BUF1_OFFSET 0x21
#define CAPTURE_DEBUG 0x19
#define SYSTEM_TO_FRAME_BUFFER 0x0
#define FRAME_BUFFER_TO_SYSTEM 0x1
#define LAST_DESCRIPTOR 1 31
#define NUM_BUFS 5
/* Should be multiple of 2. */
#define CHAR_BUF_SIZE 128
/* Should be a multiple of 4 */
#define H_SIZE 1560
#define FIELD_SIZE 307200
/*#define BUF_SIZE H_SIZE*2*/
static unsigned int volatile * MMR = NULL, *BUFF0, *BUFF1, IRQ;
static unsigned const char volatile * ATIFB = NULL;
static unsigned int saved_bus_cntl, saved_crtc_cntl;
static volatile unsigned int * full_page = NULL;
static volatile int Device_Open = 0;
int ati_module_init();
void ati_module_remove();
void ati_bh(unsigned long);
static int ati_probe_pci(struct pci_dev *, const struct pci_device_id *);
static void ati_remove_pci(struct pci_dev *);
static DECLARE_WAIT_QUEUE_HEAD(read_wait);
static DECLARE_TASKLET_DISABLED(ati_tasklet, ati_bh, 0);
static void __devexit ati_remove_pci(struct pci_dev *pdev)
{
int i;
/* Disable interrupts, then wait for a while
* to be sure.
*/
tasklet_disable(ati_tasklet);
//writel(0, (MMR + CAP_INT_CNTL / 4 ));
mdelay(20);
pci_release_regions(pdev);
/* Cast to shut up the compiler. */
iounmap((void *) ATIFB);
iounmap((void *) MMR);
devfs_unregister_chrdev(MAJOR_NUM, DEVICE_NAME);
pci_disable_device(pdev);
free_irq(IRQ, NULL);
if (full_page != NULL)
free_pages((unsigned long) full_page, 7);
printk(Removed ATI card at irq %d\n, pdev-irq);
}
/* Interrupt handler */
void ati_int (int irq, void * dev_id, struct pt_regs *regs)
{
unsigned int flags;
flags = regr (CRTC_INT_CNTL);
if (flags 0x0200)
{
regw(CRTC_INT_CNTL, flags | 0x0200);
tasklet_schedule(ati_tasklet);
}
return;
}
void ati_bh (unsigned long param)
{
wake_up_interruptible(read_wait);
return;
}
static int device_open(struct inode *inode,
struct file *file)
{
unsigned int temp;
int a;
// This is not race proof.
if (Device_Open)
return -EBUSY;
Device_Open++;
// Set VBI Window size
temp = regr (BUS_CNTL);
saved_bus_cntl = temp;
temp = (temp | 0x0800) ~(1 6); // enable mm regs and bus mastering.
regw (BUS_CNTL, temp);
temp
Re: [Dri-devel] Mach64 questions
R C writes: On Sat, Oct 13, 2001 at 10:08:50PM +0200, Manuel Teira wrote: Regarding theories on DMA and Mach64 and XFree 4.10: I just finished a module that uses the System DMA unit for video capture transfers, and it works fine under a (highly hacked) XFree 4.1.0 server. System: Dual 550 Celeron, All-in-Wonder (original) PCI, 3D Rage II+. XServer is 4.1.0 with Gatos devel branch. Module is for 2.4 kernel. To use this on another card, you would have to enter the proper PCI id in the code. Oh yes, it uses the secondary register aperture, not the linear mapped aperture, but I don't think it makes a difference. Thank you very much. I'll try to see what is missing in the GUI DMA test in the DRI code. At a first glance, I don't remember to have seen a pci_set_master call anywhere in the DRI code. It seems important, doesn't it? Have not tried GUI dma, but it is quite similar. Easier indeed. The directives in the Mach64 Programmer's manual are simpler than for the case you're working on. I'm now at work but impacient to get home and have access to the Mach64 DRI code. Thanks again. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
I spent an incredibly frustrating 4 weeks trying to get the DRI to work with r128 and g400 cards on Dell precision workstation only to find that my problem was precisely because bus mastering was NOT enabled on boot! As soon as I fixed that everything worked fine. Apparently different BIOSes WILL leave the card in different states after boot. Mike ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
On Wed, Oct 17, 2001 at 11:45:39AM +, [EMAIL PROTECTED] wrote: Thank you very much. I'll try to see what is missing in the GUI DMA test in the DRI code. At a first glance, I don't remember to have seen a pci_set_master call anywhere in the DRI code. It seems important, doesn't it? That enables bus master in the pci config registers, IIRC. Simplest test case, one descriptor: Set Frame buffer offset to 0. Set System buffer offset to 0. Set BM_COMMAND to 4096 | 1 31 (End of descriptor list). Set BM_Reserved to 0. Write bus address of buffer to BM_SYSTEM_TABLE | SYSTEM_TO_FRAME_BUFFER (which happens to be 0.) If the top line or two of your display (depends on res/depth) are corrupted, then it works. Don't forget to change the PCI_ID or the module most likely won't load. The module was written for 2.4; It shouldn't need much to backport. It does assume x86-sized ints and probably other no-nos. There are several constants I should replace with #defines, as well. I was just happy to get it working reliably on my machine. Triggering module is simple; run a dd if=/dev/atidma of=test.raw bs=307200 count=1. atidma is character device major 240 minor 0. Have not tried GUI dma, but it is quite similar. Easier indeed. The directives in the Mach64 Programmer's manual are simpler than for the case you're working on. I'm now at work but impacient to get home and have access to the Mach64 DRI code. Thanks again. No problem :) Been itching to get this working for a long time. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
Mike Westall writes: I spent an incredibly frustrating 4 weeks trying to get the DRI to work with r128 and g400 cards on Dell precision workstation only to find that my problem was precisely because bus mastering was NOT enabled on boot! As soon as I fixed that everything worked fine. Apparently different BIOSes WILL leave the card in different states after boot. Mike Thanks for your comments, guys. In three or four hours (if no new 'browns') we'll have the answer. It would be nice if this were the only problem. ;-) Anyway, I think it won't be the problem, because nobody have had success with the Mach64 Bus Mastering with the DRI ( while having success with Utah-GLX ). Perhaps XFree 3.x setup for the card is different. Best regards -- M. Teira ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 questions
On Wed, 17 Oct 2001 [EMAIL PROTECTED] wrote: Thanks for your comments, guys. In three or four hours (if no new 'browns') we'll have the answer. It would be nice if this were the only problem. ;-) Anyway, I think it won't be the problem, because nobody have had success with the Mach64 Bus Mastering with the DRI ( while having success with Utah-GLX ). Perhaps XFree 3.x setup for the card is different. Unfortunately, I don't think this is the problem. The bus master test for mach64 is not working for me and the PCI config register shows bus mastering enabled on my card: % setpci -s 01:00.0 4.w 0087 Which is 1111, bit 2 (Bus Master Enable) is set. -- Leif Delgass ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Questions about drm implemetation
Hello. I'm working in adapting the mach64 drm driver to the new template structure. I have a pair of questions: What is the meaning of the __HAVE_SG define? I've set it to zero in the mach64 driver, but I'm not sure about this supposition. In the mach64_dma.c , the following line: dev_priv-sarea = dev-maplist[0]; is now wrong, because the drm_device_t member maplist is now a drm_map_list_t* and in the mach64 trunk, it was a drm_map_t**. I'm trying to figure how to write it now, with the new type, but I'm not sure about it. Do we have to make dev_priv-sarea point to the head of the maplist? What is this supposed to be for? I've almost finished all the porting to the 4.1.0 trunk, but it have been a blind porting. I hope not to burn my laptop, because I'm still paying it. :( (If I dare to test this trunk). And finally, where is the evil register programming of the driver? Do I need to comment it? What should we need to do instead of this register programming. Could you please point me to some document of resource to know how to do it? Is the utah-glx driver implemented in this way, or could I use it as a reference? Excuse for my bad english and thanks for your time. Best regards. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
