From patchwork Tue May 24 07:16:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 68439 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp477889qge; Tue, 24 May 2016 00:16:45 -0700 (PDT) X-Received: by 10.98.59.141 with SMTP id w13mr4402469pfj.139.1464074200981; Tue, 24 May 2016 00:16:40 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l190si36518638pfc.228.2016.05.24.00.16.40; Tue, 24 May 2016 00:16:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-media-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-media-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-media-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753771AbcEXHQa (ORCPT + 4 others); Tue, 24 May 2016 03:16:30 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:50239 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753719AbcEXHQ0 (ORCPT ); Tue, 24 May 2016 03:16:26 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O7O00K0M6V9S530@mailout2.w1.samsung.com>; Tue, 24 May 2016 08:16:21 +0100 (BST) X-AuditID: cbfec7f4-f796c6d000001486-ad-5743ffc55c19 Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id E9.7B.05254.5CFF3475; Tue, 24 May 2016 08:16:21 +0100 (BST) Received: from amdc1339.digital.local ([106.116.147.30]) by eusync4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O7O00BQ16V2WW60@eusync4.samsung.com>; Tue, 24 May 2016 08:16:21 +0100 (BST) From: Marek Szyprowski To: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org Cc: Marek Szyprowski , Sylwester Nawrocki , Laurent Pinchart , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Hans Verkuil , Mauro Carvalho Chehab , Sakari Ailus Subject: [PATCH v5 1/2] media: vb2-dma-contig: add helper for setting dma max seg size Date: Tue, 24 May 2016 09:16:06 +0200 Message-id: <1464074167-27330-2-git-send-email-m.szyprowski@samsung.com> X-Mailer: git-send-email 1.9.2 In-reply-to: <1464074167-27330-1-git-send-email-m.szyprowski@samsung.com> References: <1464074167-27330-1-git-send-email-m.szyprowski@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsVy+t/xa7pH/zuHG5w8L26xccZ6VoslP3cx Wbx+YWjROXEJu0XPhq2sFjPO72OyWHvkLrvF6mcVFofftLNafNryjcmBy2PK742sHrM7ZrJ6 zDsZ6LGl/y67R9+WVYwenzfJBbBFcdmkpOZklqUW6dslcGVc+nKaveC1YsWjJbOYGxjXyHQx cnJICJhIPD//hRHCFpO4cG89G4gtJLCUUeLzTIEuRi4gu4lJ4tjl/8wgCTYBQ4mut11gRSIC ThILZ/1lByliFuhiltgy/zlYQlggQuLx6RNgU1kEVCX+X7nM2sXIwcEr4CFxpIsFYpmcxP+X K5hAbE4BT4mtvTfZQUqEgEpunKqewMi7gJFhFaNoamlyQXFSeq6hXnFibnFpXrpecn7uJkZI 0H3Zwbj4mNUhRgEORiUe3oB853Ah1sSy4srcQ4wSHMxKIryMX4BCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeefueh8iJJCeWJKanZpakFoEk2Xi4JRqYJzBsT9ki3b6lJ9v/v7eMHXe0c8BQoWT uBZxd68ROvJ0gZDDx03PP15PZXm3xuhxjMt6gePd3QuWH6nabnRddN2eCsFfa3edZJ107fP6 cN93NxqZ4u49WFGw+Yqnm6rgnCvlYmwnktOc+YxPpUZqspxh5BdfsEB4U9+Bu5/YT/D+zhNb yrRh6/ozSizFGYmGWsxFxYkAe/UXzjYCAAA= Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Add a helper function for device drivers to set DMA's max_seg_size. Setting it to largest possible value lets DMA-mapping API always create contiguous mappings in DMA address space. This is essential for all devices, which use dma-contig videobuf2 memory allocator and shared buffers. Till now, the only case when vb2-dma-contig really 'worked' was a case where userspace provided USERPTR buffer, which was in fact mmaped contiguous buffer from the other v4l2/drm device. Also DMABUF made of contiguous buffer worked only when its exporter did not split it into several chunks in the scatter-list. Any other buffer failed, regardless of the arch/platform used and the presence of the IOMMU of the device bus. This patch provides interface to fix this issue. Signed-off-by: Marek Szyprowski --- drivers/media/v4l2-core/videobuf2-dma-contig.c | 53 ++++++++++++++++++++++++++ include/media/videobuf2-dma-contig.h | 2 + 2 files changed, 55 insertions(+) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" 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-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 5361197..e3e47ac 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -753,6 +753,59 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx) } EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx); +/** + * vb2_dma_contig_set_max_seg_size() - configure DMA max segment size + * @dev: device for configuring DMA parameters + * @size: size of DMA max segment size to set + * + * To allow mapping the scatter-list into a single chunk in the DMA + * address space, the device is required to have the DMA max segment + * size parameter set to a value larger than the buffer size. Otherwise, + * the DMA-mapping subsystem will split the mapping into max segment + * size chunks. This function sets the DMA max segment size + * parameter to let DMA-mapping map a buffer as a single chunk in DMA + * address space. + * This code assumes that the DMA-mapping subsystem will merge all + * scatterlist segments if this is really possible (for example when + * an IOMMU is available and enabled). + * Ideally, this parameter should be set by the generic bus code, but it + * is left with the default 64KiB value due to historical litmiations in + * other subsystems (like limited USB host drivers) and there no good + * place to set it to the proper value. + * This function should be called from the drivers, which are known to + * operate on platforms with IOMMU and provide access to shared buffers + * (either USERPTR or DMABUF). This should be done before initializing + * videobuf2 queue. + */ +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size) +{ + if (!dev->dma_parms) { + dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL); + if (!dev->dma_parms) + return -ENOMEM; + } + if (dma_get_max_seg_size(dev) < size) + return dma_set_max_seg_size(dev, size); + + return 0; +} +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size); + +/* + * vb2_dma_contig_clear_max_seg_size() - release resources for DMA parameters + * @dev: device for configuring DMA parameters + * + * This function releases resources allocated to configure DMA parameters + * (see vb2_dma_contig_set_max_seg_size() function). It should be called from + * device drivers on driver remove. + */ +void vb2_dma_contig_clear_max_seg_size(struct device *dev) +{ + kfree(dev->dma_parms); + dev->dma_parms = NULL; +} +EXPORT_SYMBOL_GPL(vb2_dma_contig_clear_max_seg_size); + MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2"); MODULE_AUTHOR("Pawel Osciak "); MODULE_LICENSE("GPL"); diff --git a/include/media/videobuf2-dma-contig.h b/include/media/videobuf2-dma-contig.h index 2087c9a..f7dc840 100644 --- a/include/media/videobuf2-dma-contig.h +++ b/include/media/videobuf2-dma-contig.h @@ -35,6 +35,8 @@ static inline void *vb2_dma_contig_init_ctx(struct device *dev) } void vb2_dma_contig_cleanup_ctx(void *alloc_ctx); +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size); +void vb2_dma_contig_clear_max_seg_size(struct device *dev); extern const struct vb2_mem_ops vb2_dma_contig_memops;