Keith Whitwell wrote:
> Gareth Hughes wrote:
>> I *really* want to get this thing rock solid ASAP, so that we can move the rest
>> of the drivers over to the new DRM architecture. Here's the latest:
>> I have the primary DMA stream as stable as you'd like. I can send tens or
>> hundreds of megabytes of commands at the 256KB ring buffer, made up of just
>> DMAPADs, state programming commands, clears and/or swaps, and it is stable. No
>> problems at all.
>> However, throw in some secondary DMA (used for vertex buffers, texture uploads
>> etc), and we begin to get into trouble. I had Mesa/book/double running, only to
>> fire it up after restarting the X server and it locked after a couple of
>> seconds. Most other animated apps will lock up as well. I've disabled the
>> PRIMPTR register (used to write a block of status info into system memory), but
>> that doesn't seem to help.
>> I put this aside for a day or so, but will take another look at it later
>> tonight. This is mainly directed at Keith and Jeff -- is there anything I
>> should be careful of regarding secondary DMA? Any tips or tricks you guys know
>> I'm thinking about abandoning the current interrupt-driven architecture
>> altogether to see if that will help... It will, of course, remove all the
>> overhead of interrupt handling, but that's another matter...
> This would be a worthwhile experiment -- all our troubles with the original
> dma driver seemed to start when we started relying on interrupts.
> Dri-devel mailing list
I wholeheartly agree, my personal opinion is we should move to using the
interrupts only to wrap a ring buffer. Using interrupts for other
things hopelessly complicates many operations. If you look at my
experimental code written in July (interested partys should have it),
you can see this method only requires locking around writes to
PRIM_ADDRESS/PRIM_END. Any other operation is just like the other ring
buffer drivers locking/logic wise. I think the big problem with the mga
kernel driver is its convoluted locking/firing logic.
The only problem with doing DMA this way is that the hardware is REALLY
REALLY REALLY funny when it doesn't generate an interrupt but you just
rewrite PRIM_END. You have to terminate every dma transaction with a
group of DMAPAD's. You must make sure housekeeping agrees with the need
to have 5 dwords free at the end of all writes to PRIM_END. If you
don't do this the DMA engine on the hardware gets confused.
Whenever you rewrite PRIM_END without first writing PRIM_ADDRESS the
state of the hardware does not get reset. Since every DMA transaction
reads the data you tell it too + 1, this means that one dword is read
that doesn't need to be. It will be inserted into the DMA engine,
thinking it is the start of the primary block. Thus when you rewrite
PRIM_END the last 5 dwords after your transaction better have been a
valid dma block, otherwise the cards parser gets horribly confused.
While this is a little complicated, it will make the driver really damn
stable when its done.