2011/6/21 Marek Szyprowski m.szyprowski@samsung.com:
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.