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