Chris, Thanks first.
There are two more questions: 1. If I use current demos from DVEVM, like H.264 encode/decode, my application will not need CMEM? 2. Which modules depend on CMEM in current TI software framework? DSPLINK or CODEC SERVER or both? George Gu (Xiangyu Gu) Wintech Digital System Co. Beijing, China Ph: 8610-8278-2828 ext.168 Fax: 8610-8278-0028 http://www.wintechdigtal.com ---------------------------- -----Original Message----- From: Ring, Chris [mailto:[EMAIL PROTECTED] Sent: 2006年12月18日 11:25 To: George Gu; Anderberg, Niclas; [email protected] Subject: Fwd: RE: RE: CMEM and video driver issues, need your help 1. The only requirement is that the inBufs and outBufs buffers which the DSP operates on must be physically contiguous. The user can achieve this in several ways - one way is to get the buffers from a driver which ensures they're contiguous (like vpfe, as Niclas describes). Another way to get contiguous buffers, if there is no driver involved (e.g. transcoding from one file format to another) is to use buffers provided by CMEM (or using the portable Codec Engine Memory_allocContig() API calls). Again, Codec Engine doesn't care _how_ the application gets the contiguous buffers; CMEM or otherwise. 2. When the DSP decodes a video frame, the decoded frame is written into the outBufs, provided to the VIDDEC_process() call. These outBufs are provided by the application; and as described in #1, they must be physically contiguous, and can be acquired however the application wishes. Chris > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > ] On Behalf Of George Gu > Sent: Sunday, December 17, 2006 5:54 PM > To: Anderberg, Niclas; [email protected] > Subject: RE: RE: CMEM and video driver issues, need your help > > Nicals, > > Thanks for your reply. I read your mail and have new questions: > > 1. If CMEM does not copy data, then what is the usage of the pools of > CMEM? > 2. When DSP decode a video frame, it will put the raw data in to DSP > memory section----DDRALGHEAP, is it right? If yes, how these data can > be got by Linux Application? e.g. DSP will copy these data into CMEM > buffer pool? > > Thanks > > > > George Gu > (Xiangyu Gu) > Wintech Digital System Co. > Beijing, China > Ph: 8610-8278-2828 ext.168 > Fax: 8610-8278-0028 > http://www.wintechdigtal.com > ---------------------------- > > -----Original Message----- > From: > [EMAIL PROTECTED] > ncidsp.com > [mailto:[EMAIL PROTECTED] > nux.davincidsp > .com] On Behalf Of Anderberg, Niclas > Sent: 2006年12月15日 20:43 > To: George Gu; [email protected] > Subject: Fwd: RE: CMEM and video driver issues, need your help > > George, > > 1) The constraint for the DSP algorithms (actually the DSP core > itself) is that they have to work on contiguous buffers. The vpfe > device driver allocates it's own contiguous frame buffers in kernel > mode and doesn't need CMEM. > > 2) Codec Engine doesn't copy the frame buffers, it just passes a > pointer. > The DSP and ARM *physical* memory maps are identical on Davinci. > > 3) loadmodules.sh contains the worst case for any of the encode, > decode or encodedecode demos running (but not simultaneously). If you > only ever use one of the demos your pool selection would look > different. > For the demos, > you can find every Memory_contigAlloc() call and see what the worst > case buffer sizes are and put these in loadmodules.sh. > > 4) Non-cacheable from the ARM, but Codec Engine does manage cache for > these buffers from a DSP standpoint. > > Regards, > Niclas > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > ] On Behalf Of > George Gu > Sent: Friday, December 15, 2006 8:24 AM > To: [email protected] > Subject: CMEM and video driver issues, need your help > > All, > > There are some questions about CMEM and video driver, which need your > help. > > 1. Does vpfe capture buffers located in Linux Memory space? > If yes, how > does them be transferred to DSP? I guess CODEC Engine will copy them > into CMEM buffer pool first and then DSP will use these data in CMEM > buffer pool, is it right? > > 2. Base on question 1, CODEC ENGINE copy the capture data use DMA? or > memory copy? > > 3. When insert CMEM.ko, there are some parameters, such as pool counts > and pool size, how can I determine these parameters when I use a > certain codec combos, such as H264 encoder+ H264 decoder+mpeg4 > decoder??? > In TI's H264 > encodedecode demo, I found "pools=1x3145728,3x829440,1x61440,1x10240" > (loadmodules.sh), why there is a pool with 3145728 byte? > > 4. The CMEM memory is non-cacheable both for ARM and DSP? > > > Thanks very much. > > George Gu > (Xiangyu Gu) > Wintech Digital System Co. > Beijing, China > Ph: 8610-8278-2828 ext.168 > Fax: 8610-8278-0028 > http://www.wintechdigtal.com > > _______________________________________________ > 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 > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
