Thanks a lot Rob.
calling this function for each of the pointers used with CodecEngine solved the problem. However, we need something else, some function that invalidates all this virt->phy table and not each of the virtual pointers separately. Is there a way to do a full invalidate in a single call without keep tracking on each of the virtual pointers? The reason that Memory_unregisterContigBuf it is not enough for us: In our system, we allocate a very big buffer from CMEM (258048 bytes), but we don't call CodecEngine with a pointer to the big buffer. We are dividing the buffer to small slices (can be hundreds, not necessarily with the same size), and call CodecEngine with pointers to these small slices. Thus, CodecEngine keeps the pointers to the small slices in its virt->phy tables, so we need to call Memory_unregisterContigBuf for each and every one of the small slices. In the current structure of our application it is not practical for us to keep tracking on each of the slices and its size. Thanks in advance, Erez From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Tivy, Robert Sent: Wednesday, December 30, 2009 8:59 PM To: Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Subject: FW: Cmem address translation when working with Codec Engine Oops, forgot to "Reply All"... - Rob ________________________________ From: Tivy, Robert Sent: Wednesday, December 30, 2009 10:57 AM To: 'Erez Kinarti' Subject: RE: Cmem address translation when working with Codec Engine Erez, Thanks for your detailed explanation, it allows me to understand your problem and the solution. The bottom line is that you should be using CE's Memory module to allocate CMEM memory. This will alleviate your wrong phys addr to the DSP. If you want to continue using CMEM_alloc/free, then you can remove CE's cached virt->phys translation with: Memory_unregisterContigBuf(virtAddr, 258048); The reason you need to use CE's Memory module is because the codec class stub file is using it to get the phys addr of a virt buffer. What happens when you allocate outside of Memory is the following: - allocate with CMEM_alloc(), which causes the kernel to create the virt-phys mapping (there is no table in CMEM). - pass this buffer to <CODECCLASS>_process() - <CODECCLASS>_process() calls Memory_getBufferPhysicalAddress(virtAddr) - the Memory module keeps a cache of virt->phys mappings, and since Memory hasn't seen this buffer before, it asks CMEM with CMEM_getPhys(). - CMEM returns the correct phys addr and Memory caches this mapping. - you free the buffer, which frees the kernel mapping for it, then allocate a new one, and the Linux kernel creates a new mapping - the Linux kernel decides to reuse the same virt addr from before, but this time with a different phys addr - <CODECCLASS>_process() calls Memory_getBufferPhysicalAddress(virtAddr) - since Memory module didn't know about the freeing of the previous buffer, it uses its old cached translation. To allocate CMEM through Memory: Memory_AllocParams params; params.type = Memory_CONTIGPOOL; params.flags = Memory_CACHED; // or Memory_NONCACHED if so desired addr = Memory_alloc(258048, ¶ms); ... Memory_free(addr, 258048, ¶ms); Regards, - Rob ________________________________ From: Erez Kinarti [mailto:er...@radvision.com] Sent: Wednesday, December 30, 2009 12:10 AM To: Tivy, Robert; Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Hello Rob, I'm working with Amit on the same problem. Thank you very much for your quick answer and willing to help. We take the buffers directly from Cmem pool. We have a pool of 3x258048 in cmem (three buffers with size 258048), and we take one of the buffers from CMEM directly using CMEM_alloc. We do it only once for the speech codec, and this buffer is the only buffer used by us as for output buffer. After we close the codec (SPHENC_delete), we release the buffer back to CMEM directly using CMEM_free. All the CMEM allocation and free is done directly with CMEM and NOT via CodecEngine. In our case, after closing the codec and releasing the buffer, we want to reopen the codec. What we do is getting a new buffer from CMEM directly using CMEM_alloc, and then opening the codec using SPHENC_create. Another issue that is important is that in the second time, we get from CMEM a buffer with the same virtual address as the first buffer, just with different physical address. It seems like CMEM changed the virtual to physical mapping. However, when calling the DSP, it seems like CE is using the same mapping as in the first time which is no longer valid, and the DSP codec is getting a pointer to the physical buffer used in the first time. Is it possible that CMEM is changing the address translation mapping and CE is not synchronized with it and is using its old virt-to-phy mapping. Our main question: =============== What action should we do in order to synchronize the virt-to-phys cache in CE's Memory module with the CMEM virtual to physical mapping? Is there any CE command that tells CE to invalidate its virt-to-phys cache and take the updated values from CMEM? Thanks, Erez From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, December 29, 2009 7:52 PM To: Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: RE: Cmem address translation when working with Codec Engine How are you "returning CMEM buf to the pool" for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment variable called CE_DEBUG that can be set to 1|2|3. Setting it to 3 will generate lots of useful output (and lots of "noise" too, unfortunately). I don't recall if 2.10 supports CE_DEBUG or if that came after 2.10, if not then you would have to use CE_TRACE instead (which is documented). If you can run your app with this trace output enabled and send it to me I can take a look. Regards, - Rob ________________________________ From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Amit Klir Sent: Tuesday, December 29, 2009 7:26 AM To: Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: Cmem address translation when working with Codec Engine Hello, I'm working with DaVinci DM6467, using ARM running linux, and CodecEngine as the interface between ARM and DSP. My application is doing audio and video encoding in parallel in two different threads. I'm also using CMEM version 2.10 for continuous buffers allocation. The problem is that, in some situation, the CMEM buffer physical address viewed by ARM (using CMEM_getPhys()) is different than the physical address sent to DSP (translated by CodecEngine). Scenario where ArmPhyAddr != DspPhyAddr: =================================== In my application, I open CodecEngine and then open two codecs on the DSP: VIDENC1 and SPHENC1. In the beginning both codecs are running in two different threads, and for each of them we keep a CMEM buffers pool in ARM for their IO buffers. When the app starts running, for each Codec it take a single buffer from the relevant Cmem pool, and use only this buffer for all the run. In the beginning the physical addresses viewed by ARM and DSP are equal. After a while, we do the following sequence of closing and opening the codecs: 1. Close and open the video codec - VIDENC1_delete() - Return the CMEM buf of VIDENC to the pool. - Take a new CMEM buffer from the pool to be used for VIDENC. - VIDENC_create() - Running video processing of a stream ... 2. Close and open the speech codec: - SPHENC1_delete() - Return the CMEM buf of SPHENC to the pool. - Take a new CMEM buffer from the pool to be used for SPHENC. - SPHENC_create() - Running speech processing of a stream .. After doing this sequence and continue running the video and audio processing. Now on the SPHENC codec, the CMEM buffer physical address viewed by ARM is different than the one viewed by the DSP for the same buffer. In addition I see that there is a constant offset between them which is the size of a CMEM buffer used for the speech (in our case 258048). That means that the same virtual address in the ARM is translated in ARM to different physical address than the one translated by CodecEngine. It seems like two different translation tables are used, and they are not synchronized. Our CMEM pool for the speech usage is made of 3 buffers of size 258048. Does anyone know what can cause this problem? To me it seems like CMEM problem, however, when checking in TI site I see that version 2_10 that I'm using is currently the official version. Thanks in advance for any help,
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
