Per the xDAIS spec, codecs themselves never allocate memory, then only indicate (via the IALG interface) what type of memory they require... the actual allocation is delegated to the framework (e.g. Codec Engine). So the codec should never make calls malloc() itself. (One reason not to 'hack it' is that CE may not give the codec the call to free() it! Because the codec is passive, the framework can "free" the codec just by not calling it anymore and freeing its resources)
The issue is that, while xDAIS allows the codec to indicate _some_ of the memory constraints (e.g. size, alignment, etc), it doesn't define any way to indicate cacheability or physical-contiguousness. (Per my original reply, that's the gap we're intending to close in a Q3 release.) Chris > -----Original Message----- > From: > [EMAIL PROTECTED] p.com [mailto:davinci-linux-open-source-> [EMAIL PROTECTED] On Behalf Of > Vladimir Pantelic > Sent: Tuesday, May 27, 2008 11:09 AM > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355 > > Tivy, Robert wrote: > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > >> ] On Behalf Of Vladimir Pantelic > >> Sent: Tuesday, May 27, 2008 10:10 AM > >> Cc: davinci-linux-open-source@linux.davincidsp.com > >> Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355 > >> > >> Ring, Chris wrote: > >> > >> > Given that... users that need this functionality _today_ > >> may have to > >> > resort to hacks in the near term. One system-specific > hack/approach > >> > could be to modify CMEM to identify all the alloc > requests from the > >> > audio codecs (perhaps by size?), and convert all the requests > >> > identified for the audio codecs as cacheable, regardless > of whether > >> > it's asked for cacheable or not. Yes, it's a hack, but > >> might get you > >> > past this until we have more official support in xDAIS/CE. > >> > >> Couldn't the ARM side audio codec just use malloc() instead > >> of calling whatever code to request memory from CE? > >> > > If the ARM side codec uses HW accelerators then it probably > still needs > > contiguous memory from CMEM. If it's just using CPU > reads/writes then > > it could use malloc(). > > Yes, but the point is about the conflict of video codecs > needing *non-cached* > CMEM and audio codecs needing *cached* (CMEM or other) > memory. So I am asking > whether the audio codec can just use malloc()/free() to get > it's buffers instead > of going through whatever means CE offers for memory allocation. > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
