From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756218Ab1LGNlA (ORCPT ); Wed, 7 Dec 2011 08:41:00 -0500 Received: from moutng.kundenserver.de ([212.227.17.10]:49502 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755801Ab1LGNk6 (ORCPT ); Wed, 7 Dec 2011 08:40:58 -0500 From: Arnd Bergmann To: "Semwal, Sumit" Subject: Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism Date: Wed, 7 Dec 2011 13:40:35 +0000 User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; ) Cc: Rob Clark , Daniel Vetter , t.stanislaws@samsung.com, linux@arm.linux.org.uk, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, m.szyprowski@samsung.com, Sumit Semwal , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org References: <1322816252-19955-1-git-send-email-sumit.semwal@ti.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112071340.35267.arnd@arndb.de> X-Provags-ID: V02:K0:6pZHZbdtm+4566BdQ6ZTAM0HOnovHXkFrVQbpmtXFgC a/TlOV3kYUeBN+ZuIVF4CdNxdsv5pBg96v95MC8ivtIehBSMVS lAxcvSJ2BFAbY/P1SsCFWG4PIYF2gWOpnP18U4U+F+Wr+x2LIk 6vp3mhNU4+viUOsyYOEHwfd13ZYyfa1GfJB6wMRtFxxz1TZiRt 1b9V2kEjaAZCC7AtGhvSRCGoHrqqo+ZJGab8P6AR+Djqoya5e3 mXYOjDDljvWqUmzsBBHeay7LFdG/CIjMw63FfmuvFMIZlolwCS y84phQSGB5ou1wf6QR62dFYhp8FnZ2aVnEDWmj1kuERxtZt328 ioUI6ZGEYRXEpvKFS++4= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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) This issue has to be solved or we get random data corruption. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx128.postini.com [74.125.245.128]) by kanga.kvack.org (Postfix) with SMTP id 54F4B6B005C for ; Wed, 7 Dec 2011 08:40:45 -0500 (EST) From: Arnd Bergmann Subject: Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism Date: Wed, 7 Dec 2011 13:40:35 +0000 References: <1322816252-19955-1-git-send-email-sumit.semwal@ti.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112071340.35267.arnd@arndb.de> Sender: owner-linux-mm@kvack.org List-ID: To: "Semwal, Sumit" Cc: Rob Clark , Daniel Vetter , t.stanislaws@samsung.com, linux@arm.linux.org.uk, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, m.szyprowski@samsung.com, Sumit Semwal , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org 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. > 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) This issue has to be solved or we get random data corruption. Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Wed, 7 Dec 2011 13:40:35 +0000 Subject: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism In-Reply-To: References: <1322816252-19955-1-git-send-email-sumit.semwal@ti.com> Message-ID: <201112071340.35267.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. > 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) This issue has to be solved or we get random data corruption. Arnd