From patchwork Fri Aug 18 14:16:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanimir Varbanov X-Patchwork-Id: 110389 Delivered-To: patch@linaro.org Received: by 10.182.109.195 with SMTP id hu3csp889150obb; Fri, 18 Aug 2017 07:16:38 -0700 (PDT) X-Received: by 10.84.140.235 with SMTP id 98mr9763241plt.30.1503065798674; Fri, 18 Aug 2017 07:16:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1503065798; cv=none; d=google.com; s=arc-20160816; b=blTNXg28MCeY5wU04rdxVqto2ciIFDBMgFzb9/ljHQv8C4lCydL+wNBKyeQXig0nHO xRgtHC8CtrFJDBrQ4AkPk/LXBvwfcLKWJT43Z+6SrmqDBhIAQmOZiiOm+6V5n6+RyG10 +0Rxm/Qn8AbUcvLwadHWrn/xZnOw1Tk6xbKpR1Cfl3hFn57Sn9qhLhP8W5UA9wBw0jrq Oj5epvYKM94bHEMkpJxTxkI4ByA+zKXAYwPEIYL44hgMfumOFQr9Ri1+VpFJ1q3sXG26 q8Qz/IVbwlwi0CN6/rPtVlI8llGZDRG7+DK2lv4riJVa++ySpJZTcgmOZuco5HmO+vE+ 8YmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=L0g6fKOEmmncXvkdiuu40bYuuVUP8AvEIgXYB2y/Ezw=; b=wdAedo0GeVrnDLts8Mi+PSIlyZFnsLYoeJWoKDrKkRuTW5Cm/O124oyyQaiCNitvX2 MvAI22PcaDAFonlaEHIuNHyRKJGYsCP+9CC97Bq8w/1rvgR4jbjxLb/lDP7lME7kLuFh 2mSuzF9TAF86EKRxL2PL2LZ/4zLXyvMam+IVYHvaK31zU0zAnLUniSFXHm0ZepnFuU9C /VlGgRNJGR2No3gw9lPdAqgbEpIEQUROh4Ij7pgJd9KYMpw76UdguAczoiKEOopaWmt6 H8+XPoidSSfkijoklzycKPDRy7OIwpNcGbusRm+12FzakgaCZbHyH+rH8TfOx5bALhvQ 7QZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PK0iEgWJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10si3957256plu.864.2017.08.18.07.16.38; Fri, 18 Aug 2017 07:16:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PK0iEgWJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753496AbdHROQg (ORCPT + 26 others); Fri, 18 Aug 2017 10:16:36 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:37730 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752945AbdHROQd (ORCPT ); Fri, 18 Aug 2017 10:16:33 -0400 Received: by mail-wm0-f41.google.com with SMTP id i66so993952wmg.0 for ; Fri, 18 Aug 2017 07:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=L0g6fKOEmmncXvkdiuu40bYuuVUP8AvEIgXYB2y/Ezw=; b=PK0iEgWJjlWK2f16aNtwbups+9QzkbWCGNjODydq6wElPztlwzRfca9BjSKHTxkdB9 76xnAbWI7DjhJzeAG4ZM9liAl/YMaQCzRJvK8tB4CTrpz8wNhCd9AQsK4l1+r1AGtcFn yxeqaqAwZhlxURGzPWZXaOeELOuOpqq9AN1lw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=L0g6fKOEmmncXvkdiuu40bYuuVUP8AvEIgXYB2y/Ezw=; b=hz2EqgD2PEwedux9O0ORsobyL420bJR04qiaqlA5HxPWy3+v+B/XthkQ2ajzEcPnjL 7QifzFqVZW3rhSGOXMgKwbb9RRf+Yw/twc6b6KrZ32FbMJKCE+EQVZTR8aGR75zHzskj eF88IYZ6yRBCtOZL8CSiETbBkuBMLrr0gdgF+WWLGIc0YL+ywSy0C2mXWn5ZUf23aVrw m/XC0wHq1bYJr7DoOmCoFtgze/o7oaYVjOu6/5AoAfODdajq5jmJY3CF3Iq9yvB80dgX vgmByawPF5xcWVaAiDIVfEU6Udod3cZ6IqKOKCDtGHEY0cQlLweiDMca1C4e2c/jgXgL gwfQ== X-Gm-Message-State: AHYfb5gtITjU8rZRWfpIWSKoooVGjYnRLA6d5SkooNwUEdMzA3yRySUW VSpi87QNxyq1MlVO X-Received: by 10.28.19.9 with SMTP id 9mr1678615wmt.171.1503065791755; Fri, 18 Aug 2017 07:16:31 -0700 (PDT) Received: from localhost.localdomain ([37.157.136.206]) by smtp.gmail.com with ESMTPSA id 55sm1387383wrv.32.2017.08.18.07.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 07:16:31 -0700 (PDT) From: Stanimir Varbanov To: Mauro Carvalho Chehab , Hans Verkuil Cc: Pawel Osciak , Marek Szyprowski , Kyungmin Park , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Stanimir Varbanov Subject: [PATCH 1/7] media: vb2: add bidirectional flag in vb2_queue Date: Fri, 18 Aug 2017 17:16:00 +0300 Message-Id: <20170818141606.4835-2-stanimir.varbanov@linaro.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170818141606.4835-1-stanimir.varbanov@linaro.org> References: <20170818141606.4835-1-stanimir.varbanov@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This change is intended to give to the v4l2 drivers a choice to change the default behavior of the v4l2-core DMA mapping direction from DMA_TO/FROM_DEVICE (depending on the buffer type CAPTURE or OUTPUT) to DMA_BIDIRECTIONAL during queue_init time. Initially the issue with DMA mapping direction has been found in Venus encoder driver where the hardware (firmware side) adds few lines padding on bottom of the image buffer, and the consequence is triggering of IOMMU protection faults. This will help supporting venus encoder (and probably other drivers in the future) which wants to map output type of buffers as read/write. Signed-off-by: Stanimir Varbanov --- drivers/media/v4l2-core/videobuf2-core.c | 17 ++++++++--------- include/media/videobuf2-core.h | 13 +++++++++++++ 2 files changed, 21 insertions(+), 9 deletions(-) -- 2.11.0 diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 0924594989b4..cb115ba6a1d2 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -194,8 +194,6 @@ static void __enqueue_in_driver(struct vb2_buffer *vb); static int __vb2_buf_mem_alloc(struct vb2_buffer *vb) { struct vb2_queue *q = vb->vb2_queue; - enum dma_data_direction dma_dir = - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE; void *mem_priv; int plane; int ret = -ENOMEM; @@ -209,7 +207,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb) mem_priv = call_ptr_memop(vb, alloc, q->alloc_devs[plane] ? : q->dev, - q->dma_attrs, size, dma_dir, q->gfp_flags); + q->dma_attrs, size, q->dma_dir, q->gfp_flags); if (IS_ERR_OR_NULL(mem_priv)) { if (mem_priv) ret = PTR_ERR(mem_priv); @@ -978,8 +976,6 @@ static int __prepare_userptr(struct vb2_buffer *vb, const void *pb) void *mem_priv; unsigned int plane; int ret = 0; - enum dma_data_direction dma_dir = - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE; bool reacquired = vb->planes[0].mem_priv == NULL; memset(planes, 0, sizeof(planes[0]) * vb->num_planes); @@ -1030,7 +1026,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, const void *pb) mem_priv = call_ptr_memop(vb, get_userptr, q->alloc_devs[plane] ? : q->dev, planes[plane].m.userptr, - planes[plane].length, dma_dir); + planes[plane].length, q->dma_dir); if (IS_ERR(mem_priv)) { dprintk(1, "failed acquiring userspace memory for plane %d\n", plane); @@ -1096,8 +1092,6 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb) void *mem_priv; unsigned int plane; int ret = 0; - enum dma_data_direction dma_dir = - q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE; bool reacquired = vb->planes[0].mem_priv == NULL; memset(planes, 0, sizeof(planes[0]) * vb->num_planes); @@ -1156,7 +1150,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb) /* Acquire each plane's memory */ mem_priv = call_ptr_memop(vb, attach_dmabuf, q->alloc_devs[plane] ? : q->dev, - dbuf, planes[plane].length, dma_dir); + dbuf, planes[plane].length, q->dma_dir); if (IS_ERR(mem_priv)) { dprintk(1, "failed to attach dmabuf\n"); ret = PTR_ERR(mem_priv); @@ -2003,6 +1997,11 @@ int vb2_core_queue_init(struct vb2_queue *q) if (q->buf_struct_size == 0) q->buf_struct_size = sizeof(struct vb2_buffer); + if (q->bidirectional) + q->dma_dir = DMA_BIDIRECTIONAL; + else + q->dma_dir = q->is_output ? DMA_TO_DEVICE : DMA_FROM_DEVICE; + return 0; } EXPORT_SYMBOL_GPL(vb2_core_queue_init); diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index cb97c224be73..ede09fff1de8 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -427,6 +427,17 @@ struct vb2_buf_ops { * @dev: device to use for the default allocation context if the driver * doesn't fill in the @alloc_devs array. * @dma_attrs: DMA attributes to use for the DMA. + * @dma_dir: DMA mapping direction. + * @bidirectional: when this flag is set the DMA direction for the buffers of + * this queue will be overridden with DMA_BIDIRECTIONAL direction. + * This is useful in cases where the hardware (firmware) writes to + * a buffer which is mapped as read (DMA_TO_DEVICE), or reads from + * buffer which is mapped for write (DMA_FROM_DEVICE) in order + * to satisfy some internal hardware restrictions or adds a padding + * needed by the processing algorithm. In case the DMA mapping is + * not bidirectional but the hardware (firmware) trying to access + * the buffer (in the opposite direction) this could lead to an + * IOMMU protection faults. * @fileio_read_once: report EOF after reading the first buffer * @fileio_write_immediately: queue buffer after each write() call * @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver @@ -495,6 +506,8 @@ struct vb2_queue { unsigned int io_modes; struct device *dev; unsigned long dma_attrs; + enum dma_data_direction dma_dir; + unsigned bidirectional:1; unsigned fileio_read_once:1; unsigned fileio_write_immediately:1; unsigned allow_zero_bytesused:1;