On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Wednesday 07 December 2011, Semwal, Sumit wrote: >> Thanks for the excellent discussion - it indeed is very good learning >> for the relatively-inexperienced me :) >> >> So, for the purpose of dma-buf framework, could I summarize the >> following and rework accordingly?: >> 1. remove mmap() dma_buf_op [and mmap fop], and introduce cpu_start(), >> cpu_finish() ops to bracket cpu accesses to the buffer. Also add >> DMABUF_CPU_START / DMABUF_CPU_FINI IOCTLs? > > I think we'd be better off for now without the extra ioctls and > just document that a shared buffer must not be exported to user > space using mmap at all, to avoid those problems. Serialization > between GPU and CPU is on a higher level than the dma_buf framework > IMHO. Agreed. >> 2. remove sg_sync* ops for now (and we'll see if we need to add them >> later if needed) > > Just removing the sg_sync_* operations is not enough. We have to make > the decision whether we want to allow > a) only coherent mappings of the buffer into kernel memory (requiring > an extension to the dma_map_ops on ARM to not flush caches at map/unmap > time) > b) not allowing any in-kernel mappings (same requirement on ARM, also > limits the usefulness of the dma_buf if we cannot access it from the > kernel or from user space) > c) only allowing streaming mappings, even if those are non-coherent > (requiring strict serialization between CPU (in-kernel) and dma users of > the buffer) I think only allowing streaming access makes the most sense: - I don't see much (if any need) for the kernel to access a dma_buf - in all current usecases it just contains pixel data and no hw-specific things (like sg tables, command buffers, ..). At most I see the need for the kernel to access the buffer for dma bounce buffers, but that is internal to the dma subsystem (and hence does not need to be exposed). - Userspace can still access the contents through the exporting subsystem (e.g. use some gem mmap support). For efficiency reason gpu drivers are already messing around with cache coherency in a platform specific way (and hence violated the dma api a bit), so we could stuff the mmap coherency in there, too. When we later on extend dma_buf support so that other drivers than the gpu can export dma_bufs, we can then extend the official dma api with already a few drivers with use-patterns around. But I still think that the kernel must not be required to enforce correct access ordering for the reasons outlined in my other mail. -Daniel -- Daniel Vetter daniel.vetter@xxxxxxxx - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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>