Hi Brian, I'm not a Codec Engine expert, but recently I ran into a similar problem.
For one of our projects we had one physical area in memory readable and writable from: Kernel Userspace EDMA The mappings of Kernel and Userspace used different virtual addresses (and thus occupied different cache lines in cache) Problem was that when we flushed Kernel memory and started DMA, sometimes we got stale results at remote side. This was the so-called problem of "cache aliasing." We workarounded it by mapping the user virtural address space without cache (vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); remap_pfn_range(...)) and remapping the kernel visible address space with ioremap(). Thus we disabled cache for both userspace and kernelspace for this particular area. Of course this brought a serious performance penalty and certainly is not the right thing to do if you want to achieve high throughput, but at least It Worked (TM). In your case, I'd suggest that you not only invalidate/writeback the cache for the kernel-visible part, but also for the user-visible You can use these: #include <asm/cacheflush.h> flush_cache_user_range(start, end, flags); dma_flush_range(start, end); Mind that they are not EXPORT_SYMBOL()-ed, so you have to write wrappers if you want to use them in modules. HTH, Ivan Brian McFee wrote: > I'm developing a codec based on the "scale" example provided in the codec > engine package, and I'm running into some cache coherency problems: I > occasionally get stale results from the codec. To test this, all of my > output buffers are zeroed out in the application, and then set to non-zero > constants in the codec/algorithm. The output buffers are usually correct > (non-zero) upon return from the codec, but occasionally I see stale > results > (zeroes in all buffers), or a mixture of the two (some zero, some > non-zero). > > I've modified the scale example to use XDM_BufDescs for the input and > output > buffers (one large input buffer and 3 relatively small output buffers). > In > the stubs part of the extension, I've added code to step through the > BufDesc, doing the virtual-to-physical address translation for each buffer > pointer and the bufSizes arrays. Each input and output buffer is > allocated > by contigAlloc, as well as the bufSizes arrays for the BufDescs. > > Similarly, the skeleton has been modified to invalidate caches following > the > same pattern as the scale example, but now extended to iterate over all > buffers in the BufDesc. That is, first invalidate each input and output > buffer, then process, then writeback-invalidate the output buffers. Just > to > make sure I'm not crazy, I also tried hard-coding the buffer lengths into > the invalidate calls, but it doesn't seem to help. > > Could there be something screwy happening in the writeback-invalidate? > I'm > compiling with -O2, could this be affecting the cache-invalidate > operations? > > For the sake of completeness, here are the library versions I'm using: > > dvevm 1.20 > cmem 1.02 > codec engine 1.10.01 > codec servers 1.23 > dsplink 1.30.08.02 > xdais 5.10 > xdc 2.94 > > I realize that these are not the most recent versions, but I haven't found > anything (yet) in the release notes for later versions describing this > sort > of problem. > > Any help would be greatly appreciated. > > -- > Brian > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
