Hello, On Thursday, July 22, 2010 7:38 AM FUJITA Tomonori wrote: > On Tue, 20 Jul 2010 18:12:39 -0600 > Jonathan Corbet <corbet@xxxxxxx> wrote: > > > One other thing occurred to me as I was thinking about this... > > > > > + There are four calls provided by the CMA framework to devices. To > > > + allocate a chunk of memory cma_alloc() function needs to be used: > > > + > > > + unsigned long cma_alloc(const struct device *dev, > > > + const char *kind, > > > + unsigned long size, > > > + unsigned long alignment); > > > > The purpose behind this interface, I believe, is pretty much always > > going to be to allocate memory for DMA buffers. Given that, might it > > make more sense to integrate the API with the current DMA mapping > > API? > > IMO, having separate APIs for allocating memory and doing DMA mapping > is much better. The DMA API covers the latter well. We could extend > the current API to allocate memory or create new one similar to the > current. > > I don't see any benefit of a new abstraction that does both magically. That's true. DMA mapping API is quite stable and already working. > About the framework, it looks too complicated than we actually need > (the command line stuff looks insane). Well, this command line stuff was designed to provide a way to configure memory allocation for devices with very sophisticated memory requirements. It might look insane in first sight, but we haven't implemented it just for fun. We have just taken the real requirements for our multimedia devices (especially hardware video codec) tried to create a solution that would cover all of them. However I understand your point. It might be really good idea to set a default mapping as a "one global memory pool for all devices". This way the complicated cma boot argument would need to be provided only on machines that really require it, all other can use it without any advanced command line magic. > Why can't we have something simpler, like using memblock to reserve > contiguous memory at boot and using kinda mempool to share such memory > between devices? There are a few problems with such simple approach: 1. It does not provide all required functionality for our multimedia devices. The main problem is the fact that our multimedia devices require particular kind of buffers to be allocated in particular memory bank. Then add 2 more requirements: a proper alignment (for some of them it is even 128Kb) and particular range of addresses requirement (some buffers must be allocated at higher addresses than the firmware). This is very hard to achieve with such simple allocator. 2. One global memory pool heavily increases fragmentation issues and gives no way to control or limit it. The opposite solution - like having a separate pools per each multimedia device solves some fragmentation issues but it's a huge waste a of the memory. Our idea was to provide something configurable that can be placed between both solutions, that can take advantages of both. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>