On Thu, Sep 3, 2009 at 4:36 AM, Russell King - ARM Linux<linux@xxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 02, 2009 at 06:10:44PM +0300, Imre Deak wrote: >> To my understanding buffers returned by dma_alloc_*, kmalloc, vmalloc >> are ok: > > For dma_map_*, the only pages/addresses which are valid to pass are > those returned by get_free_pages() or kmalloc. Everything else is > not permitted. > > Use of vmalloc'd and dma_alloc_* pages with the dma_map_* APIs is invalid > use of the DMA API. See the notes in the DMA-mapping.txt document > against "dma_map_single". Actually, DMA-mapping.txt seems to explicitly say that it's allowed to use pages allocated by vmalloc: "It is possible to DMA to the _underlying_ memory mapped into a vmalloc() area, but this requires walking page tables to get the physical addresses, and then translating each of those pages back to a kernel address using something like __va()." >> For user mappings I think you'd have to do an additional flush for >> the direct mapping, while the user mapping is flushed in dma_map_*. > > I will not accept a patch which adds flushing of anything other than > the kernel direct mapping in the dma_map_* functions, so please find > a different approach. What's the concern here? Just the performance overhead of the checks and additional flushes? It seems much more desirable for the dma_map_* API to take care of potential cache aliases than to require every driver to manage it for itself. After all, part of the purpose of the DMA API is to manage the cache maintenance around DMAs in an architecture-independent way. -- -Steven Walter <stevenrwalter@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
