On Sat, 15 Jun 2002, Leif Delgass wrote:
>
> I forgot about that. The mach64 _does_ seem to update the word to
> indicate the bytes of the DMA buffer remaining to be processed. You write
> the number of bytes in the buffer and the DMA engine seems to decrement
> this number as it processes the buffer. We've seen this in our tests.
> It looks like we need to make this atomic and use the clear_bit as Jose
> suggested.
NOTE! Right now, clear_bit() is _not_ SMP- (and thus DMA) atomic when the
kernel is compiled as a UP kernel. There are no "dma_atomic_set_bit()"
interfaces ;(
The USB people apparently solved this some other way, I don't know what
they did (they probably just unlink the whole thing with a single atomic
write and wait for the controller to have gone through it, or something).
So right now, I think the only way to be DMA-safe on UP is to do it with
assembly.
(This, btw, is a fundamental problem: it is possible that other
architectures will have even more problems with DMA coherency, and even
the "SMP-safe" bit operations are not guaranteed to be "DMA safe").
So for now, I'd suggest just testing if doing a "lock ; andl $xxx" by hand
with inline assembly will help, and if it does, I'll have to add some
totally new DMA-safe atomic ops. But I don't want to add them before they
have been proven to be effective and used.
Linus
_______________________________________________________________
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
