On Wed, 6 Jul 2011 at 16:59:45 Arnd Bergmann wrote: > On Wednesday 06 July 2011, Nicolas Pitre wrote: > > On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > > > Another issue is that when a platform has restricted DMA regions, > > > they typically don't fall into the highmem zone. As the > > > dmabounce code allocates from the DMA coherent allocator to > > > provide it with guaranteed DMA-able memory, that would be rather > > > inconvenient. > > > > Do we encounter this in practice i.e. do those platforms requiring > > large contiguous allocations motivating this work have such DMA > > restrictions? > > You can probably find one or two of those, but we don't have to > optimize for that case. I would at least expect the maximum size of > the allocation to be smaller than the DMA limit for these, and > consequently mandate that they define a sufficiently large > CONSISTENT_DMA_SIZE for the crazy devices, or possibly add a hack to > unmap some low memory and call > dma_declare_coherent_memory() for the device. Once found that Russell has dropped his "ARM: DMA: steal memory for DMA coherent mappings" for now, let me get back to this idea of a hack that would allow for safely calling dma_declare_coherent_memory() in order to assign a device with a block of contiguous memory for exclusive use. Assuming there should be no problem with successfully allocating a large continuous block of coherent memory at boot time with dma_alloc_coherent(), this block could be reserved for the device. The only problem is with the dma_declare_coherent_memory() calling ioremap(), which was designed with a device's dedicated physical memory in mind, but shouldn't be called on a memory already mapped. There were three approaches proposed, two of them in August 2010: http://www.spinics.net/lists/linux-media/msg22179.html, http://www.spinics.net/lists/arm-kernel/msg96318.html, and a third one in January 2011: http://www.spinics.net/lists/linux-arch/msg12637.html. As far as I can understand the reason why both of the first two were NAKed, it was suggested that videobuf-dma-contig shouldn't use coherent if all it requires is a contiguous memory, and a new API should be invented, or dma_pool API extended, for providing contiguous memory. The CMA was pointed out as a new work in progress contiguous memory API. Now it turns out it's not, it's only a helper to ensure that dma_alloc_coherent() always succeeds, and videobuf2-dma-contig is still going to allocate buffers from coherent memory. (CCing both authors, Marin Mitov and Guennadi Liakhovetski, and their main opponent, FUJITA Tomonori) The third solution was not discussed much after it was pointed out as being not very different from those two in terms of the above mentioned rationale. All three solutions was different from now suggested method of unmapping some low memory and then calling dma_declare_coherent_memory() which ioremaps it in that those tried to reserve some boot time allocated coherent memory, already mapped correctly, without (io)remapping it. If there are still problems with the CMA on one hand, and a need for a hack to handle "crazy devices" is still seen, regardless of CMA available and working or not, on the other, maybe we should get back to the idea of adopting coherent API to new requirements, review those three proposals again and select one which seems most acceptable to everyone? Being a submitter of the third, I'll be happy to refresh it if selected. Thanks, Janusz -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>