I would expect that the size that you use is good enough for the Memory_registerContigBuf() call.
The only way you can query the size of the buffers allocated by CMEM is to do so in a non-direct manner, by performing "%cat /proc/cmem" and parsing the ASCII output (try out that command, you'll see what I mean). - Rob > -----Original Message----- > From: Erez Kinarti [mailto:[email protected]] > Sent: Tuesday, January 05, 2010 12:21 AM > To: Tivy, Robert; Vladimir Pantelic; > [email protected] > Subject: RE: Cmem address translation when working with Codec Engine > > Thank you very much Rob, > I'm going to try it now. > Just one open issue is the size of the big buffer: > In the app I cannot be sure what is the buffer size that CMEM > allocated for me, I just know that the size is at least the > size that I requested. > Do I have to put the size parameter in these function the > exact size allocated by CMEM, or just the size that I use is enough? > In case I must use the size allocated by CMEM, is there a way > to know what this size is? > > Thanks, > Erez > > > -----Original Message----- > From: Tivy, Robert [mailto:[email protected]] > Sent: Tuesday, January 05, 2010 1:30 AM > To: Erez Kinarti; Vladimir Pantelic; > [email protected] > Subject: RE: Cmem address translation when working with Codec Engine > > > There is no function available to invalidate all the Memory module > virt-phys translations. > > If your app structure allows it, you can call > Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, > CMEM_getPhys(bigCMEMBufferVirtAddr)); > once, and all smaller subdivided buffers will be covered by this one > registration (or, even simpler, just call > Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, > NULL); > and ignore the result, which will do the CMEM_getPhys() for you and > register it). You can then call > Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when > you're ready to free the CMEM buffer. FYI, if you want to > double-check > me, you can call Memory_dumpKnownContigBufsList() to display > (through GT > tracing) the contig buffer list (AKA, the Memory module virt-phys > translation table). > > Regards, > > - Rob > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected] > > ] On Behalf Of Erez Kinarti > > Sent: Monday, January 04, 2010 9:15 AM > > To: Vladimir Pantelic; > [email protected] > > Subject: RE: Cmem address translation when working with Codec Engine > > > > Thank you Vladimir, > > But we are not able to allocate and free via CodecEngine due > > to the structure of our application and the need to call the > > alloc not before calling CERuntimeInit(). > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected] > > ] On Behalf Of Vladimir Pantelic > > Sent: Monday, January 04, 2010 7:09 PM > > To: [email protected] > > Subject: Re: Cmem address translation when working with Codec Engine > > > > Erez Kinarti wrote: > > > 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. > > > > You dont need to call Memory_unregisterContigBuf, just alloc > > and free the buffers via CE and CE will know that you are > > calling it with a smaller buffer inside a larger one that it > > knows the translation to... > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
