Andy, Glad to hear you found the problem! SPRUE67, section 4.6 describes how to specify the masks. The easiest way is via the command line, as shown below (cut from SPRUE67). You can specify TRACEUTIL_DSP0TRACEMASK just as CE_TRACE and CE_TRACEFILE are in the example. Regards, Scott
________________________________
From: Andy Ngo [mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 3:25 PM
To: Ring, Chris; Gary, Scott
Cc: davinci-linux-open-source @linux.davincidsp.com
Subject: Re: Cache coherency issue?
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?
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
________________________________
<<attachment: Outlook.jpg>>
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
