Re: [Dri-devel] Re: Ring lockups on mach64

[Leif D. <lde...@re...>]

On Tue, 11 Jun 2002, Jos=E9 Fonseca wrote:

> Leif,
>=20
> I've got it. After adding checks and checks to everything I finally=20
> discovered it - in some circunstances (such as a regular wait_for_idle=20
> with no previous buffer submiting as an example) we were firing GUI mas=
ter=20
> without enabling the BM. It's a miracle the card even worked at all!

Now I understand why I didn't experience the lockup.  I forgot to mention
that in my tree, I renamed your do_dma_flush to do_wait_for_dma (which wa=
s
still called from do_dma_idle), and I made do_dma_flush call dma_start. =20
do_dma_flush is called by the flush ioctl, which is called before waiting
for idle by the DDX and Mesa driver, so this ensured that busmastering wa=
s
on before waiting for idle.  We still need to sort this out, because the
DDFlush in the Mesa driver should flush the ring, ensuring all buffers
will be completed by the hardware in finite time, but shouldn't wait for
idle (only DDFinish needs to wait for idle).

A couple of other comments on your change:  I think we could just=20
unconditionally turn on busmastering in SRC_CNTL if the engine is idle in=
=20
UPDATE_RING_HEAD.  One write is likely to use fewer cycles than one read,=
=20
and certainly less than one read followed by one write.  Plus, if the=20
engine is active, there shouldn't be a need to check if bus mastering is=20
on and enable it.  That also makes the do_wait_for_idle in dma_start=20
unnecessary.  The flush ioctl could just call UPDATE_RING_HEAD, and=20
possibly wait to see the head advance a couple of descriptors to make sur=
e=20
the engine won't stop.
=20
> I'm really relieved for the problem was in the code and in no way=20
> associated with the card misbehavior on slow computers!
>=20
> I think that now we can make some code cleaning. If you have no=20
> objections, I would to remove some of the code associated with the BUFF=
ER=20
> AGING=3D0, and/or when MACH64_NO_BATCH_DISPATCH=3D0.

I think that's probably fine, but I think we should see if we can salvage
the pseudo-dma path.  We should also consider what to do about frame
aging.  Also, the interrupt path is probably pretty broken now, we should=
=20
see if there's any way to make that a workable alternative or remove it.
=20
> The UPDATE_RING_HEAD macro is getting monolithical but after giving som=
e=20
> thoughs about it I've come to the conclusion that that code must really=
 be=20
> there. The only liberty we have to either leave in a macro, inline it, =
or=20
> put in a seperate directories. What I'll do it leave the most used code=
=20
> path in the macro, and define subroutines for doing the less used paths.

Maybe, if you make the changes I suggested above, all the work done in th=
e
block where the engine is idle in UPDATE_RING_HEAD could be moved into
dma_start which could be made an inline function.  At the moment, that's
the only place dma_start is called, right?
=20
> On 2002.06.10 02:37 Leif Delgass wrote:
> > ...
> >=20
> > btw, when did you last update from cvs?  I was wondering if you had t=
ried
> > the blit changes I made yesterday (June 8).
> >=20
>=20
> Yeah. I had no problem associated with them, so keep them coming!
>=20
> > ...
>=20
> Regards,
>=20
> Jos=E9 Fonseca
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?s=
ource=3Dosdntextlink
>=20
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>=20

--=20
Leif Delgass=20
http://www.retinalburn.net