Cache coherency issue?
ndno72-davinci at yahoo.com
Fri Mar 2 17:24:46 CST 2007
Thank you Chris!!!!!!!!!!!! After going through my ARM code carefully, per your suggestion, I found out I had assigned outBufs.bufSizes to 0!
I recently did a lot of cleaning up the code and renaming and replacing constants to make stuff more readable; one of my replacements had
forced outBufs.bufSizes to 0, duh! That's the reason I was getting stale data and an explicit call to Memory_cacheWbInv was required (or
apparently by just including a call to GT_trace). Thank you so much for yours and Scott's help. Hopefully this was a lesson learned
that I share with others who may be having the same problem.
I have a newbie question about TraceUtil, I'm new to using it so please forgive me. I have the following in my ARM configuration .cfg file.
var TraceUtil = xdc.useModule('ti.sdo.ce.utils.trace.TraceUtil');
TraceUtil.attrs = TraceUtil.DEFAULT_TRACING
This only turns on log "warning" (GT_6CLASS) and "error" (GT_7CLASS) messages. How do I enable other level tracing (GT_CLASS 0 to 5)
on the fly. Scott mentioned about setting TRACEUTIL_DSP0TRACEMASK="OM=012". Where is that set, the runtime environment shell or
in some configuration file"? Thanks.
----- Original Message ----
From: "Ring, Chris" <cring at ti.com>
To: Andy Ngo <ndno72-davinci at yahoo.com>; "Gary, Scott" <sg at ti.com>; Adam Dawidziuk <adam at sentivision.com>
Cc: "davinci-linux-open-source @linux.davincidsp.com" <davinci-linux-open-source at linux.davincidsp.com>
Sent: Friday, March 2, 2007 9:19:04 AM
Subject: RE: Cache coherency issue?
FWIW, I'm planning on distributing the sources to at
least the skeletons in future version of Codec Engine. You can then see
the cache operations in all their glory.
Not sure which version of CE you have, but here is a
snippet of the SPHENC skeleton (DSP-side). In red, I've
highlighted the cacheWbInv call(s) _right after_ it invokes the
codec's process() call. This is from Codec Engine
/* invalidate cache for all input and output buffers
= 0; i < inBufs.numBufs; i++)
for (i =
0; i < outBufs.numBufs; i++)
/* unmarshall outArgs based on the "size" of inArgs
pOutArgs = (ISPHENC_OutArgs *)((UInt)(&(msg->cmd.process.inArgs))
/* make the process call
/* flush cache for all output buffers
= 0; i < outBufs.numBufs; i++)
So, yes, the Codec Engine framework should be managing
your outBufs' cache for you.
Perhaps you can double-check that your outBufs.numBufs and outBufs.bufSizes is correct? outBufs.bufSizes should be the size of the _buffer_
not necessarily the size of the _contents_ of the buffer. And the codec
shouldn't be changing either of these values - they're read-only from the
It might be interesting to turn on trace as Scott
describes below - it should show exactly what cache operations are going
on. It'll be dumped into DSP-side memory, and can be 'scooped out' and
displayed by the ARM using either TraceUtils (preferred) or, if your app isn't
using TraceUtils, Engine_fwriteTrace().
Hope that helps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Davinci-linux-open-source