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.
Regards,
Andy
----- Original Message ----
From: "Ring, Chris" <[EMAIL PROTECTED]>
To: Andy Ngo <[EMAIL PROTECTED]>; "Gary, Scott" <[EMAIL PROTECTED]>; Adam
Dawidziuk <[EMAIL PROTECTED]>
Cc: "davinci-linux-open-source @linux.davincidsp.com"
<davinci-linux-open-source@linux.davincidsp.com>
Sent: Friday, March 2, 2007 9:19:04 AM
Subject: RE: Cache coherency issue?
DIV {
MARGIN:0px;}
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
1.02:
/* invalidate cache for all input and output buffers
*/
for (i
= 0; i < inBufs.numBufs; i++)
{
Memory_cacheInv(inBufs.bufs[i],
inBufs.bufSizes[i]);
}
for (i =
0; i < outBufs.numBufs; i++)
{
Memory_cacheInv(outBufs.bufs[i],
outBufs.bufSizes[i]);
}
/* unmarshall outArgs based on the "size" of inArgs
*/
pOutArgs = (ISPHENC_OutArgs *)((UInt)(&(msg->cmd.process.inArgs))
+
msg->cmd.process.inArgs.size);
/* make the process call
*/
msg->visa.status =
SPHENC_process(handle,
&inBufs,
&outBufs,
&(msg->cmd.process.inArgs), pOutArgs);
/* flush cache for all output buffers
*/
for (i
= 0; i < outBufs.numBufs; i++)
{
Memory_cacheWbInv(outBufs.bufs[i],
outBufs.bufSizes[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
codec's perspective.
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.
Chris
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
