On Sun, 28 Oct 2001, Manuel Teira wrote:
[snip]
> I still think that we should avoid more than one consecutive locks. It
> has nonsense from my point of view, at least in this case. The
> DRM_LOCK/DRM_UNLOCK macros are defined in:
> xc/programs/Xserver/hw/xfree86/os-support/xf86drm.h and a lot of other
> things I don't feel strong enough to look at now. ;-)
Yes, if we can avoid multiple locks, it's better. I did finally track
down the macros and re-read the locking doc on the PI site. The
LOCK/UNLOCK_HARDWARE macro in the mesa code looks like it is using the drm
locking scheme. I have a way to go yet to understand all the mesa stuff,
but it looks like there's a good deal of work to do there. There are a
lot of disabled bits of code and everything is being flushed with
mach64EmitHwStateLocked. We'll need to get the AGP stuff done (with
fallback for PCI) and finish the drm ioctls before we can get mesa using
DMA buffers, though. BTW, I noticed one other place where the
LOCK_TEST_WITH_RETURN can be used in mach64_dma.c in mach64_dma_idle().
> And to finish, I think that your last aproximation is the good one. I will
> look again at it this night, touch the code in that way and commit these and
> your other changes to the CVS.
OK. I did test it out doing it in the way I suggested, but I'm still
getting a lockup. I was thinking of compiling with the debugging macros
turned on to get a better idea of where the problem is. Since the problem
doesn't seem to happen with gears, I wonder if there's something in the
mesa code that isn't locking properly.
> BTW, your yesterday question:
> "do you know how to get etags to index K&R style functions like the ones in
> aticonsole.c"
> I thought that K&R style was this way:
> int foo(a,b)
> int a;
> int b;
> {
> /* Function body */
> }
>
> Or something so, isn't it?
>
> But the functions in aticonsole.c are ANSI-C defined, arent't they, but with
> a little unusual indenting:
> int
> foo(
> int a,
> int b
> )
Yes, you're right. It turns out that etags indexes these fine, but I'm
not able to expand the function list in the emacs speedbar, so it may be
that the speedbar code is using a regex that's looking for the function
names and args on the same line. I'll have to learn a little more lisp, I
think. ;)
--Leif
--
Leif Delgass
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
