From patchwork Mon Aug 21 09:09:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanimir Varbanov X-Patchwork-Id: 110506 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1010222qge; Mon, 21 Aug 2017 02:09:52 -0700 (PDT) X-Received: by 10.84.214.2 with SMTP id h2mr18222135pli.436.1503306592894; Mon, 21 Aug 2017 02:09:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1503306592; cv=none; d=google.com; s=arc-20160816; b=MdJ4C8M1pyqUkiUZk60EhJXXAS6B/1Johu54wSph2Kt69rjepzC41C2PR9gbBVbATb ExfIGhDvVNlCAZG5TXA/LQv6543FcNdqHho2l1qqExlwU9RTTu3loTqqHHCEwGQJVLTG 1den6RKJDYOZHaoxryzLAF+P2K+TeC+Xz2ARtHpxTUqBjJhuc1MedOHSRDcfZ8+Wi6jx s/RINRBTUct7sNEk2aKFD+f/UqpO9qVmvzv8ErLtnuG2k/PGZ9OerNWG0D0dHPz+Z+SI fEeDq7wxsKFkscdmIDvSgfXaYqLjYM0rPPnBUINB2DNBAaYokLbChb8f3SlWtVwRgPE+ gz6A== 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=p0oquPzy54yp9AKSp3fFZ7ePwOXKVQNF6tb93RzfN3s=; b=i7dDy26FawMAzqWe60D93Yc0eFSgHeuaTePpkD0G7UVz6c2LQLJoMhdFqr3DgewBrv czMBrBLVUXZ4Sko6167X1RUCamtLy+0JLIXOsk9yFRvvVyBZBePUN8+MWlYN8kn24LsV qqzD6WfrrP0ClPHR0svHsCoDk+RB6bWTeqG0Ktl9hpbZXAtPl+16zJlMgkBR3RLUdkBZ wWqMFnBjqrPG5GV5tG8IGC9uP4sVSHNFdK1VeAfRaiSY/ISGgZILkLkRVeV/OhgnSjEC E4oocODow/nznZRKY97KYVMFnrWZoGXff5/LJRxUBXrbfx/nkYA50ARrTf4XLd2n4Gr4 xi0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=S+rePryw; spf=pass (google.com: best guess record for domain of linux-arm-msm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-arm-msm-owner@vger.kernel.org; dmarc=fail (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 k15si6854629pgc.939.2017.08.21.02.09.52; Mon, 21 Aug 2017 02:09:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-arm-msm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=S+rePryw; spf=pass (google.com: best guess record for domain of linux-arm-msm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-arm-msm-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdHUJJv (ORCPT + 9 others); Mon, 21 Aug 2017 05:09:51 -0400 Received: from mail-wr0-f177.google.com ([209.85.128.177]:35278 "EHLO mail-wr0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751897AbdHUJJu (ORCPT ); Mon, 21 Aug 2017 05:09:50 -0400 Received: by mail-wr0-f177.google.com with SMTP id k46so18511299wre.2 for ; Mon, 21 Aug 2017 02:09:49 -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=6GNIEh0W9XeurAMQBlqGnZhpOnl+vUnJFbzcCZbPMK4=; b=S+rePrywraIZ6//6JrHLlH43DBtIKNOsehIgFlT1v70yQHyXKsvmrI4jRvo8I2wke/ RNVQCSEVNaGSORUxOP2cMhPS2rukLyUw/6nMNqxdz5bhZ/SWH05Z7xsgbb7feLVijM88 8jWZlRJK6UrO2xhvHywyeDzd19nrjhaDI2dAA= 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=6GNIEh0W9XeurAMQBlqGnZhpOnl+vUnJFbzcCZbPMK4=; b=msZ0lvIGPGByXZ0y9l90uzItYIbzdhXabUu1gqvT8lxFXFYYzi8kTGN0V6Wahl1QKs 8V5rAfQYUkp9UGCl13WoHtie+UkUq3rxjjT/7RnWhAZLukkg5eoSJn4TQegauw/lgT4G mQveWfw7rT5ofOYVSH/Xsn82tSN6IlvkS4y/kFEqGVEIoad85B7yNw4KYLWsc44RqnpK 1TU4H4rVDiXdZ3hWfBDNHEhrkFgB8BPiWWXG0N//L5GOdl/aYz+OcNJ5HpOjhc9cHQ7B 2bN/gxf6EWe13mF/NQiyPA+RkWhZDWjJ3npjLEXpjujFtH15Jv96w/6TCHuuxkN7yIpj QgFw== X-Gm-Message-State: AHYfb5hzArjUKaz5siI/sBvSoC7zUwNIBWTzug7+uS4weX6Y795FYR4X gG7bWQLsVaSZO+fL X-Received: by 10.28.179.9 with SMTP id c9mr5090686wmf.17.1503306588932; Mon, 21 Aug 2017 02:09:48 -0700 (PDT) Received: from localhost.localdomain ([37.157.136.206]) by smtp.gmail.com with ESMTPSA id 52sm19490488wrt.38.2017.08.21.02.09.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Aug 2017 02:09:48 -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 v2] media: vb2: add bidirectional flag in vb2_queue Date: Mon, 21 Aug 2017 12:09:09 +0300 Message-Id: <20170821090909.32614-1-stanimir.varbanov@linaro.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170818141606.4835-2-stanimir.varbanov@linaro.org> References: <20170818141606.4835-2-stanimir.varbanov@linaro.org> Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@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 --- v2: move dma_dir into private section. drivers/media/v4l2-core/videobuf2-core.c | 17 ++++++++--------- include/media/videobuf2-core.h | 13 +++++++++++++ 2 files changed, 21 insertions(+), 9 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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..ef9b64398c8c 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -427,6 +427,16 @@ 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. + * @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 @@ -465,6 +475,7 @@ struct vb2_buf_ops { * Private elements (won't appear at the uAPI book): * @mmap_lock: private mutex used when buffers are allocated/freed/mmapped * @memory: current memory type used + * @dma_dir: DMA mapping direction. * @bufs: videobuf buffer structures * @num_buffers: number of allocated/used buffers * @queued_list: list of buffers currently queued from userspace @@ -495,6 +506,7 @@ struct vb2_queue { unsigned int io_modes; struct device *dev; unsigned long dma_attrs; + unsigned bidirectional:1; unsigned fileio_read_once:1; unsigned fileio_write_immediately:1; unsigned allow_zero_bytesused:1; @@ -516,6 +528,7 @@ struct vb2_queue { /* private: internal use only */ struct mutex mmap_lock; unsigned int memory; + enum dma_data_direction dma_dir; struct vb2_buffer *bufs[VB2_MAX_FRAME]; unsigned int num_buffers;