Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: > On Wed, Dec 15, 2010 at 12:39:20PM +0000, Catalin Marinas wrote: > > > > Should we not try to fix the generic code and still allow platforms > > to use dma_declare_coherent_memory() in a safer way? I guess it may > > need some arguing/explanation on linux-arch. > > I think so - Hi Russel, I've already started implementing what you've suggested, with an already working result, but have two questions: 1. Is it save to leave iounmap() being called on virtual addresses not obtained with ioremap()? This would make things less complicated. 2. Can I quote your full explanation, just like it looks below, in my commit message? Thanks, Janusz Wednesday 15 December 2010 18:01:42 Russell King - ARM Linux wrote: > ... one of the issues with dma_declare_coherent_memory() is > that it's original intention (as I understand it) was to allow > drivers to use on-device dma coherent memory. > > Eg, a network controller with its own local SRAM which it can fetch > DMA descriptors from, which tells it where in the bus address space > to fetch packets from. This SRAM is not part of the hosts memory, > but is on the peripheral's bus, and so ioremap() (or maybe > ioremap_wc()) would be appropriate for it. > > However, ioremap() on system RAM (even that which has been taken out > on the memory map) may be problematical. > > I think the correct solution would be to revise the interface so it > takes a void * pointer, which can be handed out by > dma_alloc_coherent() directly without the API having to worry about > how to map the memory. IOW, push the mapping of that memory up a > level to the caller of > dma_declare_coherent_memory(). > > We can then sanely do preallocations via dma_coherent_alloc() and > caching them back into dma_declare_coherent_memory() without creating > additional mappings which cause architectural violations. -- 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
