2011/6/21 Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>: > > You already got a reply that dropping dma_alloc_writecombine() is no > go on ARM. > Yes. > That's not a problem. Once we agree on dma_alloc_attrs(), the drivers > can be changed to use DMA_ATTR_WRITE_COMBINE attribute. If the platform > doesn't support the attribute, it is just ignored. That's the whole > point of the attributes extension. Once a driver is converted to > dma_alloc_attrs(), it can be used without any changes either on platforms > that supports some specific attributes or the one that doesn't implement > support for any of them. > I just worried that removing an existing construct is not a simple job. You introduced 3 attributes: DMA_ATTR_WRITE_COMBINE, ***COHERENT and ***NO_KERNEL_VADDR I replied earlier, I also indicated that write combining option for dma_alloc_*() is required. But it does not mean dma_map_ops must support that. I think dma_alloc_writecombine() can be implemented regardless of dma_map_ops. > Allocation is a separate operation from mapping to userspace. Mmap > operation should just map the buffer (represented by a cookie of type > dma_addr_t) to user address space. > > Note that some drivers (like framebuffer drivers for example) also > needs to have both types of mapping - one for user space and one for > kernel virtual space. I meant that I think DMA_ATTR_NOKERNELVADDR is not required because you also introduced mmap callback. -- 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>