Hi,
This nasty problem got me mad!!
I am now using DVEM6446 board and DVSDK enviroment to develop a ARM
client + DSP video decoder application.
Now i found that sometimes the bitstream buffer which is transferred by
ARM to DSP exists dirty data case.
Detail information about this case were given here:
(1) the bitstream buffer was pre-allocated at ARM side, via
Memory_contigAlloc() function;
[ in my opinion, Memory_contigAlloc() should provide buffers which
were not only aligned,
but also non-cached and physically contiguous.
Isn't it right??
]
(2) each time when i call the VIDDEC_process() interface at ARM side, i
pass the bitstream buffer
pointer via the "XDM_BufDesc inBufs" parameter. e.g.:
streamBuf = Memory_contigAlloc(800000, -1);
................
actualStreamSize = fread(streamBuf, 1, 800000, fp);
................
inBufs.numBufs = 1;
inBufAddr[0] = streamBuf;
inBufSize[0] = actualStreamSize;
inBufs.bufs[0] = inBufAddr;
inBufs.bufSizes[0] = inBufSize;
printf("ARM : 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
*((unsigned char *)inBufAddr[0]+0),
*((unsigned char *)inBufAddr[0]+1),
*((unsigned char *)inBufAddr[0]+2),
*((unsigned char *)inBufAddr[0]+3),
*((unsigned char *)inBufAddr[0]+4),
*((unsigned char *)inBufAddr[0]+5));
/* Call the process function to decode the nalu buffers */
status = VIDDEC_process(hdecode,
&inBufs,
&outBufs,
(IVIDDEC_InArgs *)(&decoder_inargs),
(IVIDDEC_OutArgs *)(&decoder_outargs));
................
(3) each time when the dsp-side IVIDDEC_process() function is called, i
invaliate the cache related to
bitstream buffer. e.g:
XDAS_Int32 IVIDDEC_process(IVIDDEC_Handle h, XDM_BufDesc *inBufs,
XDM_BufDesc *outBufs,
IVIDDEC_InArgs *inArgs, IVIDDEC_OutArgs
*outArgs)
{
int i;
for ( i = 0; i < inBufs->numBufs; i ++ )
{
GT_6trace(curDecTrace, GT_ENTER, "DSP : before invalid: 0x%x
0x%x 0x%x 0x%x 0x%x 0x%x\n",
*((unsigned char *)inBufs->bufs[i]+0),
*((unsigned char *)inBufs->bufs[i]+1),
*((unsigned char *)inBufs->bufs[i]+2),
*((unsigned char *)inBufs->bufs[i]+3),
*((unsigned char *)inBufs->bufs[i]+4),
*((unsigned char *)inBufs->bufs[i]+5));
BCACHE_inv(inBufs->bufs[i], inBufs->bufSizes[i], TRUE);
//invaildate cache
GT_6trace(curDecTrace, GT_ENTER, "DSP : after invalid: 0x%x
0x%x 0x%x 0x%x 0x%x 0x%x\n",
*((unsigned char *)inBufs->bufs[i]+0),
*((unsigned char *)inBufs->bufs[i]+1),
*((unsigned char *)inBufs->bufs[i]+2),
*((unsigned char *)inBufs->bufs[i]+3),
*((unsigned char *)inBufs->bufs[i]+4),
*((unsigned char *)inBufs->bufs[i]+5));
}
.............
decode_one_frame(inBufs, .....);
............
}
While, the experiment results show that sometimes the data readden by
DSP are inconsistent with
the datat written by ARM, and if inconstistent case exists, it seems
that the data readden by dsp
in this time is the same data with the data written by ARM last time,
How to fix this problem?
Is the cache on ARM side unflushed (if Memory_contigAlloc() provides
buffers with cachalility) ?
or is the cache on DSP side ninvalidated unsucessfully (if
BCACHE_inv() is a void function )?
I got mad! Help me, please?!!!
This message (including any attachments) is for the named addressee(s)'s use
only. It may contain
sensitive, confidential, private proprietary or legally privileged information
intended for a
specific individual and purpose, and is protected by law. If you are not the
intended recipient,
please immediately delete it and all copies of it from your system, destroy any
hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of this
message and/or any
attachments is strictly prohibited.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
