Kmalloc problem

Sorted after a massive amount of googling:

http://stackoverflow.com/questions/5940101/allocating-more-than-4-mb-of-pinned-contiguous-memory-in-the-linux-kernel

FWIW, we typically recommend CMEM (from the Linux Utils product in your EZSDK/DVSDK) for this:

    http://processors.wiki.ti.com/index.php/CMEM_Overview

Chris

_Ralph_ said:

Having quickly refreshed my memory on this I can see that the main drawback is that you have to manually specify the start and end addresses of the physical block. This makes it unsuitable for dynamically allocating buffers as there is no guarantee that those buffers will still be free after booting. Ideally the CMEM module would use the kernel page allocator to work out which contiguous address range to allocate.... but then it would fail because the kernel would refuse to allocate more than 2^(MAX_ORDER-1) pages at a time.

Using CMEM, you create a carveout (typically using MEM= on the Linux cmd line) so Linux doesn't really  know about the memory.  Assuming adequate memory was carved out, "dynamic" allocation will always succeed since we're not using Linux's kernel allocator at all (CMEM's allocator takes care of it).

Without better kernel support, this is the simple-to-understand approach we developed several years ago, and it remains today.  Good news is that the kernel community sees this as an issue and is looking at adding a "CMA" (Contiguous Memory Allocator) feature into the kernel in the [hopefully near] future.  We're monitoring this, and prototyping putting CMEM user mode APIs on top of CMA.  This would give you the benefits of CMEM's API set (alloc/free, cache, virt2phys, etc) with the additional benefits of CMA (when the memory isn't allocated, the kernel can use it for other things).  CMA is still being discussed and reviewed, but it looks like it'll be added to the mainline kernel this year.

_Ralph_ said:

As a side note, the entire reason that we are having to use one large physical buffer is because the IOMMU on the DSP is broken (and I IIRC believe Codec Engine uses physical addresses anyway by its fundamental design?).

I can neither confirm nor deny that with certainty, but I think you're right about the DSP's MMU being broken.  :/  Strictly speaking, CE is responsible for translating addresses from user-side virt to "whatever the remote proc can see".  Today that's physical addresses (and worse, physically contiguous addresses)  b/c the slave has no MMU.  But assuming the slave has an MMU, CE could add a feature to scatter/gather memory into the slave-side's MMU (so it looks virtually contiguous to the slave), and pass the slave that [now virtual, and virtually contiguous] address for the slave to work on.  Don't have that support today, though.

Chris