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
