Cache coherency issue?

Andy Ngo 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.

Regards, 
Andy



----- 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?



 
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



  
  
  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070302/8c6a4b61/attachment.htm


More information about the Davinci-linux-open-source mailing list