From patchwork Mon May 8 15:03:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sakari Ailus X-Patchwork-Id: 9716357 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8CC8E6035D for ; Mon, 8 May 2017 15:05:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 810FE2094F for ; Mon, 8 May 2017 15:05:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 760F424151; Mon, 8 May 2017 15:05:14 +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=-4.2 required=2.0 tests=BAYES_00, 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 36DAC205F6 for ; Mon, 8 May 2017 15:05:14 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D7E8D6E267; Mon, 8 May 2017 15:04:41 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 844DA6E259 for ; Mon, 8 May 2017 15:04:36 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 08:04:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.38,309,1491289200"; d="scan'208"; a="1145112654" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga001.fm.intel.com with ESMTP; 08 May 2017 08:04:33 -0700 Received: from nauris.fi.intel.com (nauris.localdomain [192.168.240.2]) by paasikivi.fi.intel.com (Postfix) with ESMTP id 2EDEB213B3; Mon, 8 May 2017 18:04:27 +0300 (EEST) Received: by nauris.fi.intel.com (Postfix, from userid 1000) id 6F9B7201AC; Mon, 8 May 2017 18:03:32 +0300 (EEST) From: Sakari Ailus To: linux-media@vger.kernel.org Subject: [RFC v4 15/18] vb2: Dma direction is always DMA_TO_DEVICE in buffer preparation Date: Mon, 8 May 2017 18:03:27 +0300 Message-Id: <1494255810-12672-16-git-send-email-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1494255810-12672-1-git-send-email-sakari.ailus@linux.intel.com> References: <1494255810-12672-1-git-send-email-sakari.ailus@linux.intel.com> Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, hverkuil@xs4all.nl, kyungmin.park@samsung.com, laurent.pinchart@ideasonboard.com, posciak@chromium.org, m.szyprowski@samsung.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP The patch changes the DMA direction from DMA_FROM_DEVICE to DMA_TO_DEVICE for capture buffers. The DMA API does not require that any synchronisation is done to the buffer when it is passed to hardware for writing _but_ there's a caveat: the user *must not* have written to the buffer. The V4L2 API does however not require this. Instead, it requires that the user does not access the buffer since it is queued to the device using VIDIOC_QBUF IOCTL until the buffer is dequeued again using VIDIOC_DQBUF IOCTL. So in this case we want to ensure there will be no dirty cache lines that could end up to memory possibly after the device has written to the same memory area. What data gets written to the system memory from the cache is not extremely important. Still, an for debugging purposes an application capturing images could fill the buffer with a known pattern which will be overwritten by the device, hence DMA_TO_DEVICE. If an application can guarantee that it has not written to the buffer, it can specify the V4L2_BUF_FLAG_NO_CACHE_SYNC flag to omit the sync operation. Signed-off-by: Sakari Ailus --- drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index f572911..320e53a 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -103,7 +103,7 @@ static void vb2_dc_prepare(void *buf_priv) */ if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt)) dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, - buf->dma_dir); + DMA_TO_DEVICE); } static void vb2_dc_finish(void *buf_priv) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index 5662f00..88b2530 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -206,7 +206,7 @@ static void vb2_dma_sg_prepare(void *buf_priv) */ if (buf->dma_attrs & DMA_ATTR_NON_CONSISTENT) dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, - buf->dma_dir); + DMA_TO_DEVICE); } static void vb2_dma_sg_finish(void *buf_priv)