Message ID | 20221113150511.8878-1-lukasz.wiecaszek@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1723063wru; Sun, 13 Nov 2022 07:26:16 -0800 (PST) X-Google-Smtp-Source: AA0mqf66B6YYGd+R2s7hZiaZRq9zd28FLLKF42sSU8ninrFXrS8weDWRhvhwbRCpNcnSfxljXlwJ X-Received: by 2002:a65:5908:0:b0:46f:1e8f:1633 with SMTP id f8-20020a655908000000b0046f1e8f1633mr8705145pgu.556.1668353175839; Sun, 13 Nov 2022 07:26:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668353175; cv=none; d=google.com; s=arc-20160816; b=H45DyIbBiQ8IK9A/DktG7tY2uJnvwAFj8OgIpkIRSVObmert+5TFARyLdMMT6hKhOB fghl9qHDwfBiqhRyvKCbK+vK3sfuZM0SZNVXL0KUVaV5TTMI8n6GGivH/gYGwHe+VEYk vV+dC02DJdKySRp1HChnQGpHf42X1KI3gPfXT85kNgd+RckA6rZ7DlRpg8kiJw8zp9dE Gsy3MzfSMwL8c1CGEkbSHn1FX8CnoNN8PaLQU1c0sUu05xAlzrcnHNWz/7JMq+1GU86J p6RmgiUR2JZ6snwiyeH2kIG0DQQT+LvU/1jQmETdupQEkMtLFl5U6V68Exp6dcI76isp vpAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=umo/xdUlQSYAVDNNJIA7iJ7EdK6y2kGfWONuMRbs/TA=; b=wqM5D7ipnziyxGzcHAVwYGtlREB/XasIITVy9gNqBNy5jNS6AY/00pf3JSFU6HpnYs ginQ8sJap8syFaiaTB7AU1bFzGcjT6eY0ZiUmQsdQFRzltxFrcSRCUe4H//Z5IN+4mR1 +2SM7x+mBBXraj23EwaevbMVuDTp9msVkAOL8ayKZYACmhxhiVbks7vQh6SY7SS7FBSz hIl9rClzknsWtJNZFClsmGoCODmganqr+RaozOQLXWBHV/9dsJuI4YM7uqtqr7XDCXga tzICWFLcp6v3EFwbYF81UnplL0kJnKzANKCPqQGFz0ipWWCLPCLYixG9IS1LgOjesPxL srdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=e9lTnIly; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f16-20020a056a001ad000b00565cb1ebdb2si7181621pfv.267.2022.11.13.07.25.56; Sun, 13 Nov 2022 07:26:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=e9lTnIly; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235232AbiKMPHa (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Sun, 13 Nov 2022 10:07:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232676AbiKMPH3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 13 Nov 2022 10:07:29 -0500 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 641BBCE19; Sun, 13 Nov 2022 07:07:27 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id a29so15424777lfj.9; Sun, 13 Nov 2022 07:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=umo/xdUlQSYAVDNNJIA7iJ7EdK6y2kGfWONuMRbs/TA=; b=e9lTnIlyKgsqjF+MrXGgxFYkfUbeoadmoDhRaLkeApmUoQyroEV1yTWy4iBDU1GumZ 62VNSeshYUqjvZZbIHfhXRtyMracJ8xvEOAczV4BS+SEd1pi2iigs1dHU9Wxb7YtmCLx xjGJM9yQZtIv/IbvoNb5hKb2yBGm3fJMxDNLcE68BXXRZQr1yfj5gAME1iZDEz+89it6 GrCDPrM3HbifmuqJMEfb3MKlY9t+1IJrgG+fqEJIVXBe424P41VyQoxGToyLhgwYCFNH Syk3lZzZGTXghlpw64V8xD+ing6+wBvllMX82FHDHhzDUF7YjizxP5TBsHt7LGylUMwG l97w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=umo/xdUlQSYAVDNNJIA7iJ7EdK6y2kGfWONuMRbs/TA=; b=pZrD6CxrZwzUiQpC125o/md6Y9DyUf6Uxgt6ttmV10BROj+aOwZxpMqOOsSUTI80IM TYC/kZXSijkdR4m1dQK2sJ0RkWlmF1QgZ/027XhcGo/n0TLOpjbBGMxf04YCLYRzQ5gK TG6y1yNEWCsjKRroNLjmPUQG6CPxz6T5u8NDmcOLMa57vgIGlZ603ZKKipy2LcS8PFXj tw0xD9ajRnaMFaDV9PWsD6tK7bGpismHOBGHL5tJf5yIXjPUx7id1u2KUoEBe/V6LmVG yFkx26CFpR1aLBTzVEAotT37XKnNA9NmS33xmzXPy1GqOvEO+gpdJflGXAGjQugdMV18 MfZg== X-Gm-Message-State: ANoB5pnKI1xFUhx9/HV5NAHmZMGxtAPeKfaDVvW3vWkiRapHflrVwtn8 LdnPSIW101AGrp2IN+ImcqU= X-Received: by 2002:a05:6512:2305:b0:4b1:8698:9f3e with SMTP id o5-20020a056512230500b004b186989f3emr2911401lfu.421.1668352045590; Sun, 13 Nov 2022 07:07:25 -0800 (PST) Received: from localhost.localdomain (185-48-128-212.net.cybernetwmw.com. [185.48.128.212]) by smtp.googlemail.com with ESMTPSA id j26-20020ac2455a000000b004979ec19387sm1397753lfm.305.2022.11.13.07.07.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Nov 2022 07:07:25 -0800 (PST) From: Lukasz Wiecaszek <lukasz.wiecaszek@googlemail.com> X-Google-Original-From: Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com> To: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>, Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com>, kernel test robot <lkp@intel.com>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] udmabuf: add vmap method to udmabuf_ops Date: Sun, 13 Nov 2022 16:05:11 +0100 Message-Id: <20221113150511.8878-1-lukasz.wiecaszek@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749395099716887843?= X-GMAIL-MSGID: =?utf-8?q?1749395099716887843?= |
Series |
[v2] udmabuf: add vmap method to udmabuf_ops
|
|
Commit Message
Lukasz Wiecaszek
Nov. 13, 2022, 3:05 p.m. UTC
The reason behind that patch is associated with videobuf2 subsystem
(or more genrally with v4l2 framework) and user created
dma buffers (udmabuf). In some circumstances
when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem
wants to use dma_buf_vmap() method on the attached dma buffer.
As udmabuf does not have .vmap operation implemented,
such dma_buf_vmap() natually fails.
videobuf2_common: [cap-000000003473b2f1] __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each
videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: buffer for plane 0 changed
videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: failed to map dmabuf for plane 0
videobuf2_common: [cap-000000003473b2f1] __buf_prepare: buffer preparation failed: -14
The patch itself seems to be strighforward.
It adds implementation of .vmap method to 'struct dma_buf_ops udmabuf_ops'.
.vmap method itself uses vm_map_ram() to map pages linearly
into the kernel virtual address space (only if such mapping
hasn't been created yet).
Signed-off-by: Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
---
v1: https://lore.kernel.org/linux-media/202211120352.G7WPASoP-lkp@intel.com/T/#t
v1 -> v2: Patch prepared and tested against 6.1.0-rc2+
drivers/dma-buf/udmabuf.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Comments
On 11/13/22 18:05, Lukasz Wiecaszek wrote: > The reason behind that patch is associated with videobuf2 subsystem > (or more genrally with v4l2 framework) and user created > dma buffers (udmabuf). In some circumstances > when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem > wants to use dma_buf_vmap() method on the attached dma buffer. > As udmabuf does not have .vmap operation implemented, > such dma_buf_vmap() natually fails. > > videobuf2_common: [cap-000000003473b2f1] __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each > videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: buffer for plane 0 changed > videobuf2_common: [cap-000000003473b2f1] __prepare_dmabuf: failed to map dmabuf for plane 0 > videobuf2_common: [cap-000000003473b2f1] __buf_prepare: buffer preparation failed: -14 > > The patch itself seems to be strighforward. > It adds implementation of .vmap method to 'struct dma_buf_ops udmabuf_ops'. > .vmap method itself uses vm_map_ram() to map pages linearly > into the kernel virtual address space (only if such mapping > hasn't been created yet). > > Signed-off-by: Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com> > Reported-by: kernel test robot <lkp@intel.com> > --- > v1: https://lore.kernel.org/linux-media/202211120352.G7WPASoP-lkp@intel.com/T/#t > > v1 -> v2: Patch prepared and tested against 6.1.0-rc2+ > > drivers/dma-buf/udmabuf.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index 2bcdb935a3ac..2ca0e3639360 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -12,6 +12,8 @@ > #include <linux/slab.h> > #include <linux/udmabuf.h> > #include <linux/hugetlb.h> > +#include <linux/vmalloc.h> > +#include <linux/iosys-map.h> > > static int list_limit = 1024; > module_param(list_limit, int, 0644); > @@ -26,6 +28,7 @@ struct udmabuf { > struct page **pages; > struct sg_table *sg; > struct miscdevice *device; > + void *vaddr; > }; > > static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) > @@ -57,6 +60,21 @@ static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) > return 0; > } > > +static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > +{ > + struct udmabuf *ubuf = buf->priv; > + > + if (!ubuf->vaddr) { > + ubuf->vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); > + if (!ubuf->vaddr) > + return -EINVAL; > + } > + > + iosys_map_set_vaddr(map, ubuf->vaddr); > + > + return 0; > +} > + > static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > enum dma_data_direction direction) > { > @@ -159,6 +177,7 @@ static const struct dma_buf_ops udmabuf_ops = { > .unmap_dma_buf = unmap_udmabuf, > .release = release_udmabuf, > .mmap = mmap_udmabuf, > + .vmap = vmap_udmabuf, > .begin_cpu_access = begin_cpu_udmabuf, > .end_cpu_access = end_cpu_udmabuf, > }; Where is vunmap?
On 11/13/22 18:05, Lukasz Wiecaszek wrote: > +static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > +{ > + struct udmabuf *ubuf = buf->priv; > + > + if (!ubuf->vaddr) { > + ubuf->vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); > + if (!ubuf->vaddr) > + return -EINVAL; > + } Create a new mapping on each vmap_udmabuf() and add the corresponding vunmap. Otherwise persistent vmapping shall be released together with udmabuf. It doesn't look that persistent vmapping is needed for udmabufs.
On Sun, Nov 13, 2022 at 07:35:20PM +0300, Dmitry Osipenko wrote: > On 11/13/22 18:05, Lukasz Wiecaszek wrote: > > +static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > > +{ > > + struct udmabuf *ubuf = buf->priv; > > + > > + if (!ubuf->vaddr) { > > + ubuf->vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); > > + if (!ubuf->vaddr) > > + return -EINVAL; > > + } > > Create a new mapping on each vmap_udmabuf() and add the corresponding > vunmap. > > Otherwise persistent vmapping shall be released together with udmabuf. > It doesn't look that persistent vmapping is needed for udmabufs. > > -- > Best regards, > Dmitry Right. Thanks for review and remarks. Adding vunmap sounds reasonable to me. Will add it somehow this week. Regards, Lukasz
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 2bcdb935a3ac..2ca0e3639360 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -12,6 +12,8 @@ #include <linux/slab.h> #include <linux/udmabuf.h> #include <linux/hugetlb.h> +#include <linux/vmalloc.h> +#include <linux/iosys-map.h> static int list_limit = 1024; module_param(list_limit, int, 0644); @@ -26,6 +28,7 @@ struct udmabuf { struct page **pages; struct sg_table *sg; struct miscdevice *device; + void *vaddr; }; static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) @@ -57,6 +60,21 @@ static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) return 0; } +static int vmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) +{ + struct udmabuf *ubuf = buf->priv; + + if (!ubuf->vaddr) { + ubuf->vaddr = vm_map_ram(ubuf->pages, ubuf->pagecount, -1); + if (!ubuf->vaddr) + return -EINVAL; + } + + iosys_map_set_vaddr(map, ubuf->vaddr); + + return 0; +} + static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, enum dma_data_direction direction) { @@ -159,6 +177,7 @@ static const struct dma_buf_ops udmabuf_ops = { .unmap_dma_buf = unmap_udmabuf, .release = release_udmabuf, .mmap = mmap_udmabuf, + .vmap = vmap_udmabuf, .begin_cpu_access = begin_cpu_udmabuf, .end_cpu_access = end_cpu_udmabuf, };