Don't know if my previous reply got through: The simplest way to not break anything existing and extend to allow algorithms to ask for cacheable and non cacheable memory would be to extend the enumeration (SARAM0, DARAM0) and include new ones which now indicate whether cacheable or non cacheable memory is requested.
perhaps it also makes sense to seperate cacheable v/s non cacheable from contigous from non contigous (Don't know how it will be implemented though). You may not want to tie physical continuity with cacheability (In the future we could have cacheable and non cacheable cmem and cacheable and non cacheable malloc memory, who knows what the future demands). But come to think of it, either we can choose to break xdais or extend the enumeration to include better types and ask all to move to newer ones. Let me know what you think. On Wed, May 28, 2008 at 12:38 AM, Ring, Chris <[EMAIL PROTECTED]> wrote: > You can try rand()... lemme know how that works out for you. ;) > > We need to get xDAIS updated to understand these other memory spaces - > it's long overdue. We just haven't seen customer demand force the issue > as most xDAIS codecs are running on more embedded OS's (like DSP BIOS) > without virtual memory or where cacheability on a per-buffer granularity > isn't feasible. Linux is a good place to help push xDAIS forward... but > we've got some growing pain to get through. > > Chris > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > ] On Behalf Of Vladimir Pantelic > > Sent: Tuesday, May 27, 2008 11:46 AM > > Cc: [email protected] > > Subject: Re: Cache issue with MPEG4 Encoder / Decoder on DM355 > > > > Ring, Chris wrote: > > > 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) > > > > ah, ok, didn't know that. > > > > > 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.) > > > > Yes, I was just trying to find a more clever hack, how about > > rand() instead of > > malloc(), no free() needed :-) > > > > > > > > > > _______________________________________________ > > 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
