I'm not really a codec or XDAIS guy, but I believe it would violate some codec
coding standard (probably XDAIS) to call cache functions inside the codec
process call.
With Codec Engine's skeletons there is a way for the codec to tell the
skeleton to perform a cache operation after returning from the process call (by
setting an 'accessMask' structure element), but this applies only to outBufs
usually.
What CE codec class are you using? IVIDDEC? IVIDDEC1? Different codec
classes have different cache management operations in the skeletons, so a
different one than what you're using today could help with your cache
management.
Regards,
- Rob
From: Sriraja Yagneswaran [mailto:sriraja_yagneswa...@mindtree.com]
Sent: Tuesday, November 17, 2009 8:34 PM
To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Passing buffers to Codec engine as inArgs params
Thanks Robert,
I'm unsure about where exactly would the cache invalidation and writeback
functions be called. Would if be sufficient if I do cache management within the
process call of my DSP codec (before and after the buffers are used ) or do
they have to appear elsewhere (i.e. do I have to build a customized stub and
skeleton for the codec that includes the cache management for the extra
buffers?)
Regards
Sriraja
From: Tivy, Robert [mailto:rt...@ti.com]
Sent: Tuesday, November 17, 2009 11:41 PM
To: Sriraja Yagneswaran; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Passing buffers to Codec engine as inArgs params
Codec Engine has mechanisms in place to manage the cache for inBufs outBufs
being transferred between an ARM and DSP, but there is no cache management for
inArgs/outArgs. Perhaps this is your problem and you could try to manage the
cache for these buffers manually using the CE osal's Memory interface?
Regards,
- Rob
From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On
Behalf Of Sriraja Yagneswaran
Sent: Tuesday, November 17, 2009 12:44 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Passing buffers to Codec engine as inArgs params
I have a setup as described below:
A capture device on the ARM side that gives me an input frame that contains
data for 4 input channels interleaved as 4 quadrants of a larger frame. To
supply the 4 processes with input data I make 4 copies of the captured frame
(capture copy buffers). The copy buffers are allocated contiguous memory on the
ARM though the CMEM pools. The physical memory of the copy buffers is obtained
and shared among the processes.
Another buffer of the larger size is allocated through CMEM and its physical
memory is also shared (display copy buffer). This is for the processes to write
back the processed data and display them.
The 4 processes make a codec engine call with the physical address of their
respective capture copy buffer is passed as input argument (extended inArgs).
This is done as the buffer itself is created in another ARM application and not
readily available for the current application context. Within the DSP process
call each of the process copies out their relevant quadrants to work on them.
The DSP process call also writes its processed buffer back into the
corresponding quadrant of the display copy buffer before returning from the DSP.
On the ARM side the display copy buffer is copied to the display buffer and
sent to the device for display.
We have put a signaling mechanism around the codec engine process calls on the
ARM side for 4 codec engine + capture applications such that they execute in
a serial manner (i.e. one starts only after the previous one has returned).
This setup runs and seems to function as intended but hangs at intermittent
times (sometime after 10+ hours). One of our suspicions is on the usage of the
copy buffers (that are being used on both ARM and DSP side without being passed
as either inBufs or outBufs).
Please advise if such a usage is correct and if some sanity checks are
possible. Alternative suggestions for usage are also welcome.
Thanks
Sriraja
http://www.mindtree.com/email/disclaimer.html
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
