Darren, You can always do 'cat /proc/cmem' which will tell you which pools have been created and which buffers are in use.
Combined with gdb single stepping through your allocation code this should tell you what's missing. Regards, Niclas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren J Longhorn Sent: Tuesday, February 13, 2007 2:04 PM To: [email protected] Subject: Re: CMEM Monk, Roger wrote: > Hi Darren, > > These are the contiguous memory pools (size and number of) that you > want to configure for your application. In the standard dvevm setup, > these are configured to support the requirements of the demos. The > Memory_contigAlloc() as you mention below uses these pools to allocate > the memory for sharing between ARM/DSP. > > The demo apps use the following contig memory sizes, hence the > configuration in the loadmodules.sh script for cmem. > > 3145728 - video bitstream buffer (READBUFSIZE = 3 * 1024 * 1024) - > 1off 829440 - video buffers (D1_MAX_FRAME_SIZE = 720 * 576 * 2) - 3 > off > > 61440 - audio bitstream buffer (READBUFSIZE = 60 * 1024) - 1 off > 10240 - audio buffers (SOUNDBLKSIZE * 5 = 2 * 1024 * 5) - 1 off > Yeah, that makes sense, it's sort of what I assumed. It's just that when I tried reducing the pools to exactly what I need for my new test app, I got input/output error when doing insmod on the CMEM kernel object. _______________________________________________ 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
