Unfortunately, VIDENC_OutArgs.reconBufs is not supported in Codec Engine
when the codec is "remote" and the application is running on an OS with
virtual memory (like Linux) - exactly our typical DVEVM environment.
The rationale is that today's xDM interface (version 0.9) defines no
formal interface for ownership of these buffers, where they can be
located, how long they're valid after process() returns, etc.
In general, the ARM application and/or framework don't know where the
buffers are, so we'd have to map the entire DSP address space into the
Linux application's process - which will consume a large number of Linux
resources. Also, generally, "the DSP address space" can change from one
DSP image to another, so it's difficult for a general purpose framework
like CE to ensure we always "get this right".
Also, some implementations of the codecs may generate these
reconstruction buffers in shared scratch memory, and as such it may be
trashed before - or during - ARM-side accesses. In general, because the
semantics of the reconstruction buffers aren't defined by the spec, each
codec can "do things their own way", and it's difficult (and/or costly
from a resource POV) to support.
This is, IMHO, a limitation of the xDM 0.9 API, and is planned to be
addressed in the xDM 1.0 interfaces. In the 1.0 xDM interfaces, the
semantics of reconstruction buffer usage is that the ARM will provide
these buffers to the DSP, similar to today's outBufs. The DSP will fill
these buffers and return them to the application upon returning from
process(). In this way, there can be a formal ownership model between
the processors, and cache maintenance and address translation can be
accomplished.
FYI, the xDM 1.0 beta interfaces are included in xDAIS 5.10, available
here:
https://www-a.ti.com/downloads/sds_support/targetcontent/XDAIS/xdais_5_1
0/index.html
Note all the comments about support - and lack of it - once the xDM 1.0
interfaces are finalized in a future xDAIS release (planned for early
2007)
Chris
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of X. Zhou
Sent: Tuesday, November 14, 2006 11:42 PM
To: [email protected]
Subject: Is it impossile for arm to access the physical memory
taken exclusively by dsp?
Hi, group, another question about XDAIS compilant codecs running
on DM6446 DVSDK.
Is it possible to access the memory taken exclusively by DSP (
i.e.: not the memory taken by ARM linux kernel, CMEMK module, and
DSPLINK module) from ARM side?
actually, my issue comes from this fact:
(1) the dsp algorithm allocates some buffers to contain some
critical data, e.g.: reconstruced image data;
(2) now, i want to print these data from ARM side. i know theere
is DSP traceutil tool i can use, but I prefer to read these data from
arm client application, so i make use of IVIDENC_OutArgs to get the
address of that buffer, e.g.:
a). at dsp algorithm side, in each IVIDENC_**_process()
call, i set IVIDEnc_OutArgs just like below:
outArgs->reconBufs.numBufs = 1;
outArgs->reconBufs.width = DSP_BUF_STRIDE;
outArgs->reconBufs.bufs[0] = DSP_BUF_ADDR;
outArgs->reconBufs.bufSizes[0] = DSP_BUF_SIZE;
b). at arm client application, after each VIDENC_process()
call, i intend to access the dsp buffer just like below:
status = VIDENC_process(hencode,
&inbuf_desc,
&outbuf_desc,
&encoder_inargs,
&encoder_outargs);
........
bufPhyAddr = encoder_outargs.reconBufs.bufs[0];
bufSize = encoder_outargs.reconBufs.bufSizes[0];
bufLogAddr =
Memory_getBufferVirtualAddress(bufPhyAddr, bufSize);
fwrite(bufLogAddr, bufSize, 1, fp);
......
While, i founded that the "bufPhyAddr" gotten by arm is always
equal to be 0 !!! I feel very confused!
anyway, i also tried to pass the bufPhyAddr via other fileld
of encoder_outargs.reconBufs, except the bufs fields. It seems
sucessfully, but the Memory_getBufferVirtualAddress() call failed!
Is it impossile for arm to access the physical memory taken
exclusively by dsp?
if does, how can i do for this requirement?
ZhouXiao
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
