From patchwork Thu Jul 4 16:37:25 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Price X-Patchwork-Id: 11032225 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5DBC414DB for ; Fri, 5 Jul 2019 08:41:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 49B8428A1E for ; Fri, 5 Jul 2019 08:41:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3BB7B28A24; Fri, 5 Jul 2019 08:41:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D7C5C28A1E for ; Fri, 5 Jul 2019 08:41:52 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F2FB36E43B; Fri, 5 Jul 2019 08:41:23 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 2D2FF6E390; Thu, 4 Jul 2019 16:37:49 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9B01F2B; Thu, 4 Jul 2019 09:37:48 -0700 (PDT) Received: from e112269-lin.arm.com (e112269-lin.cambridge.arm.com [10.1.196.133]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7B6873F703; Thu, 4 Jul 2019 09:37:47 -0700 (PDT) From: Steven Price To: Sumit Semwal , Daniel Vetter Subject: [PATCH] dma-buf: Update docs to discourage use of dma_buf_mmap() Date: Thu, 4 Jul 2019 17:37:25 +0100 Message-Id: <20190704163725.18050-1-steven.price@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: References: MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 05 Jul 2019 08:41:20 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org, Steven Price , Rob Herring , Alyssa Rosenzweig , Boris Brezillon , ML mesa-dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP dma_buf_mmap() allows a device driver to forward a mmap() call to the dma_buf exporter. However this mechanism provides no way for userspace to use the DMA_BUF_IOCTL_SYNC mechanism to ensure coherency with the mapped buffer. Because of this it is wise to migrate away from providing this mmap() forwarding mechanism and update drivers to avoid using it. However the user ABI must be maintained, so this existing mmap() forwarding cannot be removed. Signed-off-by: Steven Price --- drivers/dma-buf/dma-buf.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index bf4d4c80fbc6..2a7a2c8c4182 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -731,20 +731,17 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); * * - And as a CPU fallback in userspace processing pipelines. * - * Similar to the motivation for kernel cpu access it is again important that - * the userspace code of a given importing subsystem can use the same - * interfaces with a imported dma-buf buffer object as with a native buffer - * object. This is especially important for drm where the userspace part of - * contemporary OpenGL, X, and other drivers is huge, and reworking them to - * use a different way to mmap a buffer rather invasive. + * Ideally userspace code should directly mmap the dma-buf fd which allows + * the use of the SYNC_START/SYNC_END ioctls as detailed above. However there + * are situations where there is a large body of existing code and reworking + * it to support a different way to mmap a buffer is rather invasive. * - * The assumption in the current dma-buf interfaces is that redirecting the - * initial mmap is all that's needed. A survey of some of the existing - * subsystems shows that no driver seems to do any nefarious thing like - * syncing up with outstanding asynchronous processing on the device or - * allocating special resources at fault time. So hopefully this is good - * enough, since adding interfaces to intercept pagefaults and allow pte - * shootdowns would increase the complexity quite a bit. + * Some drivers therefore provide an interface that simply redirects the + * mmap to the dma-buf exporter. This is fine as long as the SYNC_START and + * SYNC_END ioctls don't do anything, but may lead to coherency issues + * if they are required. New code should avoid using this because of + * potentially hard to debug coherency problems. The interface, however, + * remains for backwards compatibility. * * Interface:: * int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*,