On Tue, 11 Jun 2002, José Fonseca wrote: > Leif, > > I've got it. After adding checks and checks to everything I finally > discovered it - in some circunstances (such as a regular wait_for_idle > with no previous buffer submiting as an example) we were firing GUI master > 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 was still called from do_dma_idle), and I made do_dma_flush call dma_start. 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 was 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 unconditionally turn on busmastering in SRC_CNTL if the engine is idle in UPDATE_RING_HEAD. One write is likely to use fewer cycles than one read, and certainly less than one read followed by one write. Plus, if the engine is active, there shouldn't be a need to check if bus mastering is on and enable it. That also makes the do_wait_for_idle in dma_start unnecessary. The flush ioctl could just call UPDATE_RING_HEAD, and possibly wait to see the head advance a couple of descriptors to make sure the engine won't stop. > I'm really relieved for the problem was in the code and in no way > associated with the card misbehavior on slow computers! > > I think that now we can make some code cleaning. If you have no > objections, I would to remove some of the code associated with the BUFFER > AGING=0, and/or when MACH64_NO_BATCH_DISPATCH=0. 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 see if there's any way to make that a workable alternative or remove it. > The UPDATE_RING_HEAD macro is getting monolithical but after giving some > thoughs about it I've come to the conclusion that that code must really be > there. The only liberty we have to either leave in a macro, inline it, or > put in a seperate directories. What I'll do it leave the most used code > 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 the 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? > On 2002.06.10 02:37 Leif Delgass wrote: > > ... > > > > btw, when did you last update from cvs? I was wondering if you had tried > > the blit changes I made yesterday (June 8). > > > > Yeah. I had no problem associated with them, so keep them coming! > > > ... > > Regards, > > José Fonseca > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - >http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
