Hi. On Tue, Jun 14, 2011 at 12:07 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > I'm sure that the graphics people will disagree with you on that. > Having the frame buffer mapped in write-combine mode is rather > important when you want to efficiently output videos from your > CPU. > I agree with you. But I am discussing about dma_alloc_writecombine() in ARM. You can see that only ARM and AVR32 implement it and there are few drivers which use it. No function in dma_map_ops corresponds to dma_alloc_writecombine(). That's why Marek tried to add 'alloc_writecombine' to dma_map_ops. > I can understand that there are arguments why mapping a DMA buffer into > user space doesn't belong into dma_map_ops, but I don't see how the > presence of an IOMMU is one of them. > > The entire purpose of dma_map_ops is to hide from the user whether > you have an IOMMU or not, so that would be the main argument for > putting it in there, not against doing so. > I also understand the reasons why dma_map_ops maps a buffer into user space. Mapping in device and user space at the same time or in a simple approach may look good. But I think mapping to user must be and driver-specific. Moreover, kernel already provides various ways to map physical memory to user space. And I think that remapping DMA address that is in device address space to user space is not a good idea because DMA address is not same to physical address semantically if features of IOMMU are implemented. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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>