Andy,
The framework should indeed be handling the necessary buffer invalidates
before, and writebacks after, calling the algorithm's process function.
To verify this you could try turning on trace, (as in the archived
message), and you should see similar statements indicating the
operations on the specific buffers. The mask name for these memory
calls is "OM". If you are using TraceUtil, you can specify
CE_TRACE="OM=012".
I don't know if they apply, but some general things to be careful of:
- Make sure your buffers are contiguous, cache-line aligned, and sized
as an integral number of cache lines.
- DSP should not write to IN buffers.
- OUT buffers should not be used to pass data to DSP.
Hope this helps.
Regards,
Scott
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Andy Ngo
Sent: Thursday, March 01, 2007 1:54 PM
To: Andy Ngo; Adam Dawidziuk
Cc: davinci-linux-open-source @linux.davincidsp.com
Subject: Re: Cache coherency issue?
OK, I got desperate and need to get my codec work correctly
right away. So I tried forcing a write-back invalidate on the
output buffers and now everything seems to work fine; before
SPHENC_process returns, I called the following to write-back
invalidate the output buffers:
Memory_cacheWbInv(outBufs->bufs[0], size);
I don't know why the XDAIS framework layer is not doing that
automatically for me. Any thoughts anyone?
Thanks to X. Zhou
(http://www.mail-archive.com/[EMAIL PROTECTED]
com/msg00960.html)
<http://www.mail-archive.com/[EMAIL PROTECTED]
com/msg00960.html>
for bringing this up (and still, no one has really given a clear
answer).
Regards,
Andy
----- Original Message ----
From: Andy Ngo <[EMAIL PROTECTED]>
To: Adam Dawidziuk <[EMAIL PROTECTED]>
Cc: "davinci-linux-open-source @linux.davincidsp.com"
<[email protected]>
Sent: Wednesday, February 28, 2007 10:46:21 PM
Subject: Re: Cache coherency issue?
Adam,
Thanks for the quick response. I'm not quite sure what you are
saying. I basically took the example
sphenc_copy codec as a template and customized it to create my
own speech enc codec. All
the configurations (contents in .tcf and .cfg) pretty much
stayed the same. My codec algorithm does not
explicitly call any DMA functions so I'm not sure how I'm
"accessing the output buffers both
by the CPU and DMA". I added a lot of code and data to the
codec so the only change I can
see is the increase in memory usage of the DDR region (4MB code,
stack, static data). How can
I debug this issue to see if the DSP and DMA are accessing the
output buffers as you suggested?
Like you said, this seems like a caching problem. I guess I'll
try to handle the cache coherency myself,
which the Framework is supposed to do for me automatically.
Anyone, any thoughts.
Regards,
Andy
----- Original Message ----
From: Adam Dawidziuk <[EMAIL PROTECTED]>
To: Andy Ngo <[EMAIL PROTECTED]>
Cc: "davinci-linux-open-source @linux.davincidsp.com"
<[email protected]>
Sent: Wednesday, February 28, 2007 9:09:49 PM
Subject: Re: Cache coherency issue?
Andy,
Don't get me wrong by personally I think you don't exactly
follow DMA
rules in your algorithm. It seems that for some reason you
access the
output buffers both by CPU and DMA. Thus some part of data are
left in
cache, and some are in external memory. GT_trace probably access
all
your data by CPU thus performing automatic write-back when cache
runs out.
Are you 100% sure your data is coherent upon returning from the
process
call, presumably all in external memory?
Hope you figure out the way and share this with community. I
would
certainly want to see what's going on, sine I had strange cache
coherency problems myself...
Best,
Andy Ngo wrote:
> According to a previous post
>
(http://www.mail-archive.com/[EMAIL PROTECTED]
com/msg00960.html),
> the XDAIS Framework is suppose to handle cache coherency
automatically
> (points 1-4 in the post above). Recently, I have
> been adding more and more code and data to my DSP speech codec
and I've
> been getting weird problems with the data exchanged
> between the ARM and the DSP. For example, I would always get
the same
> exact data on the output buffer from a call
> to SPHENC_process. In attempt to debug the problem, I put a
GT_trace
> call in my DSP speech codec to print out the data
> that was being returned from SPHENC_process so that I can
compare it to
> the data I saw being returned to on the ARM side.
> Weird thing is that by putting GT_trace in the speech codec,
the problem
> went away (the return data is different each time).
> As soon as I comment out the call to GT_trace, the problem
came back
> (ARM side sees same data being returned).
>
> Am I doing something wrong? Is there a cache cohency problem
here? Why
> does adding a simple GT_trace fix the problem and
> my data looks correct? Instead of GT_trace, I tried putting
some hard
> delays in an attempt to affect timing but that wouldn't
> work, only a call to GT_trace work. I've been on this for
several days now.
>
> Please advise. Thanks in advance.
>
> Regards,
> Andy
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
>
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
Adam Dawidziuk
Sentivision
_______________________________________________
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
