From: Yunfei Dong <yunfei.dong@mediatek.com>
To: "Jeffrey Kardatzke" <jkardatzke@google.com>,
"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
"Nathan Hebert" <nhebert@chromium.org>,
"Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
"Hans Verkuil" <hverkuil-cisco@xs4all.nl>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Sebastian Fricke" <sebastian.fricke@collabora.com>,
"Tomasz Figa" <tfiga@chromium.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>
Cc: "Chen-Yu Tsai" <wenst@chromium.org>,
"Yong Wu" <yong.wu@mediatek.com>,
"Hsin-Yi Wang" <hsinyi@chromium.org>,
"Fritz Koenig" <frkoenig@chromium.org>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Steve Cho" <stevecho@chromium.org>,
"Yunfei Dong" <yunfei.dong@mediatek.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T . J . Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: [PATCH v7 03/28] media: videobuf2: calculate restricted memory size
Date: Sat, 20 Jul 2024 15:15:41 +0800 [thread overview]
Message-ID: <20240720071606.27930-4-yunfei.dong@mediatek.com> (raw)
In-Reply-To: <20240720071606.27930-1-yunfei.dong@mediatek.com>
Getting the physical address with sg_dma_address for restricted memory,
only return the first physical address size since sg may not be physical
continuous, then leading to the dmabuf size is small than buf size. Need
to bypass continuous checking for restricted memory.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../common/videobuf2/videobuf2-dma-contig.c | 34 +++++++++++++++----
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 3d4fd4ef5310..f0e4652b615f 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -66,6 +66,22 @@ static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
return size;
}
+/**************************************************/
+/* restricted mem scatterlist table functions */
+/**************************************************/
+
+static unsigned long vb2_dc_get_res_mem_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ unsigned int i;
+ unsigned long size = 0;
+
+ for_each_sgtable_dma_sg(sgt, s, i)
+ size += sg_dma_len(s);
+
+ return size;
+}
+
/*********************************************/
/* callbacks for all buffers */
/*********************************************/
@@ -648,10 +664,13 @@ static void *vb2_dc_get_userptr(struct vb2_buffer *vb, struct device *dev,
goto fail_sgt_init;
}
- contig_size = vb2_dc_get_contiguous_size(sgt);
+ if (buf->vb->vb2_queue->restricted_mem)
+ contig_size = vb2_dc_get_res_mem_contiguous_size(sgt);
+ else
+ contig_size = vb2_dc_get_contiguous_size(sgt);
if (contig_size < size) {
- pr_err("contiguous mapping is too small %lu/%lu\n",
- contig_size, size);
+ pr_err("contiguous mapping is too small %lu/%lu/%u\n",
+ contig_size, size, buf->vb->vb2_queue->restricted_mem);
ret = -EFAULT;
goto fail_map_sg;
}
@@ -711,10 +730,13 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
}
/* checking if dmabuf is big enough to store contiguous chunk */
- contig_size = vb2_dc_get_contiguous_size(sgt);
+ if (buf->vb->vb2_queue->restricted_mem)
+ contig_size = vb2_dc_get_res_mem_contiguous_size(sgt);
+ else
+ contig_size = vb2_dc_get_contiguous_size(sgt);
if (contig_size < buf->size) {
- pr_err("contiguous chunk is too small %lu/%lu\n",
- contig_size, buf->size);
+ pr_err("contiguous chunk is too small %lu/%lu/%u\n",
+ contig_size, buf->size, buf->vb->vb2_queue->restricted_mem);
dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt,
buf->dma_dir);
return -EFAULT;
--
2.18.0
next prev parent reply other threads:[~2024-07-20 7:17 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-20 7:15 [PATCH v7 00/28] media: mediatek: add driver to support secure video decoder Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 01/28] v4l2: add restricted memory flags Yunfei Dong
2024-07-20 9:13 ` Hans Verkuil
2024-07-20 7:15 ` [PATCH v7 02/28] v4l2: handle restricted memory flags in queue setup Yunfei Dong
2024-07-20 9:20 ` Hans Verkuil
2024-07-20 9:53 ` Hans Verkuil
2024-07-20 7:15 ` Yunfei Dong [this message]
2024-07-20 9:29 ` [PATCH v7 03/28] media: videobuf2: calculate restricted memory size Hans Verkuil
2024-07-20 7:15 ` [PATCH v7 04/28] dma-buf: heaps: Deduplicate docs and adopt common format Yunfei Dong
2024-07-25 11:52 ` Christian König
2024-07-25 18:28 ` T.J. Mercier
2024-07-20 7:15 ` [PATCH v7 05/28] dma-heap: Add proper kref handling on dma-buf heaps Yunfei Dong
2024-07-20 15:13 ` Markus Elfring
2024-07-22 18:06 ` John Stultz
2024-07-22 18:38 ` Markus Elfring
2024-07-20 7:15 ` [PATCH v7 06/28] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 07/28] media: mediatek: vcodec: add tee client interface to communiate with optee-os Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 08/28] media: mediatek: vcodec: build decoder OPTEE driver as module Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 09/28] media: mediatek: vcodec: allocate tee share memory Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 10/28] media: mediatek: vcodec: send share memory data to optee Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 11/28] media: mediatek: vcodec: initialize msg and vsi information Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 12/28] media: mediatek: vcodec: add interface to allocate/free secure memory Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 13/28] media: mediatek: vcodec: using shared memory as vsi address Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 14/28] media: mediatek: vcodec: add single allocation format Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 15/28] media: mediatek: vcodec: support " Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 16/28] media: mediatek: vcodec: support single allocation buffer Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 17/28] media: mediatek: vcodec: re-construct h264 driver to support svp mode Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 18/28] media: mediatek: vcodec: remove parse nal_info in kernel Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 19/28] media: mediatek: vcodec: disable wait interrupt for svp mode Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 20/28] media: mediatek: vcodec: support tee decoder Yunfei Dong
2024-07-20 7:15 ` [PATCH v7 21/28] media: mediatek: vcodec: move vdec init interface to setup callback Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 22/28] media: mediatek: vcodec: support hevc svp for mt8188 Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 23/28] media: mediatek: vcodec: support av1 svp decoder " Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 24/28] media: mediatek: vcodec: support vp9 " Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 25/28] media: mediatek: vcodec: remove vsi data from common interface Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 26/28] media: mediatek: vcodec: rename vsi to extend vsi Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 27/28] media: mediatek: vcodec: adding non extend struct Yunfei Dong
2024-07-20 7:16 ` [PATCH v7 28/28] media: mediatek: vcodec: support extend h264 driver Yunfei Dong
2024-11-13 12:20 ` [PATCH v7 00/28] media: mediatek: add driver to support secure video decoder Sebastian Fricke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240720071606.27930-4-yunfei.dong@mediatek.com \
--to=yunfei.dong@mediatek.com \
--cc=Brian.Starkey@arm.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=frkoenig@chromium.org \
--cc=hsinyi@chromium.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jkardatzke@google.com \
--cc=jstultz@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=m.szyprowski@samsung.com \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=nfraprado@collabora.com \
--cc=nhebert@chromium.org \
--cc=nicolas.dufresne@collabora.com \
--cc=sebastian.fricke@collabora.com \
--cc=stevecho@chromium.org \
--cc=sumit.semwal@linaro.org \
--cc=tfiga@chromium.org \
--cc=tjmercier@google.com \
--cc=wenst@chromium.org \
--cc=yong.wu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox