I am required to dump encoder reconstructed buffer. Memory to this buffer is supplied by DSP using memTab to codec. Pointer to this buffer is provided in outArgs.reconBufs.bufDesc[].buf. I am able to get valid buffer pointer if I access outargs from DSP side. If I try to access the buffer from ARM side, I get NULL buffer pointer.
Any idea why ???
I am using CE version 2_10_02. Platform is DM6467.
Couple more details... this is a IVIDENC1-codec?
Assuming 'yes', your comment about the reconBufs are memTab-allocated is a bit concerning... in general, the ARM can only see buffers it allocates. The IVIDENC1 interface defines that the reconBufs are provided by the app (via the outBufs[1-3]) for exactly this reason. See the details about the reconBufs field here:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ce/latest_2_x/docs/html/struct_i_v_i_d_e_n_c1___out_args.html
Chris
Yes, this is IVIDENC1-codec. Since the buffers are provided to codec using memTab, ARM has no way to see the buffer pointer??? Is there any workaround??
If I understand the issue correctly, this codec violates the IVIDENC1 XDM spec. :( So any workaround would be codec specific... but we can discuss options. At the end of the day, the codec should be fixed.
Since the DM6467 doesn't have a DSP-side MMU, the physical addresses are the same from both processors. So if you can find the location of the DSP-side memTab dynamically allocated to the codec for its reconstruction buffers, your ARM-side app could mmap() that physical buffer into its virtual address space (likely non-cached so as not to introduce Linux-side cache coherency issues) and then access the memory from the ARM.
How can you get this address? You could define a custom control() cmd id and update the codec to return the memTab's physical address value (via extended Status struct) when it receives this new control() cmd. Or if the codec is always provided the same block of memory, you could hard-code it into your Linux-side app.
Others on this forum may be able to provide the usermode code necessary to map physical memory into a processes virtual address space.
These complexities are precisely why the interface was designed the way it was... and is why the ultimate fix is to make the codec comply with the IVIDENC1 spec.
Thanks for suggestion!
ARM is seeing DDR address as 0x41xxxxxx while DSP see address as 0x8xxxxxxx. I tried the workaround by allocating reconbuf memory from ARM9 side. I used XDM_GETBUFINFO and XDM_SETBUFINFO for that. Codec is providing back application the pointer to reconstructed frame in outArgs.reconBuf.bufDesc. Application is still seeing the reconbuf pointer value as NULL. Other paramters like size and pitch are fine. I have verified the codec is writing pointers correctly and it is also seen correctly by VIDENC1_process() call in videnc1.c file.
Any clue further???
For completeness, this issue was resolved off thread, and I'll post the general resolution here.
The root cause was that the codec was returning a buffer (base + size) that was outside the range of the buffer provided by the ARM - and therefore, the ARM-side address translation of DSP-side phys to ARM-side virt address was failing. This was detected using the Memory_dumpKnownContigBufsList() API, and observing that the base + size of the codec-returned reconstruction buffer was not completely within the range of any 'known contiguous buffers'.
In this case, the actual data _was_ within a known contig buffer, but the buffer the codec was returning was larger than the data - something like this:
ARM-provided buffer-to-fill: [ ]DSP-returned buffer ('X' is data): [XXXXXXX ]
Once the DSP-side codec was modified to [correctly] return a buffer that was within a valid range - i.e., within the range of the buffer sent by the ARM - these address translations could succeed... something like this:
ARM-provided buffer-to-fill: [ ] DSP-returned buffer ('X' is data): [XXXXXXX]