From: Robin Murphy <robin.murphy@arm.com>
To: Tomasz Figa <tfiga@chromium.org>, Anle Pan <anle.pan@nxp.com>,
Christoph Hellwig <hch@lst.de>
Cc: m.szyprowski@samsung.com, mchehab@kernel.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
hui.fang@nxp.com
Subject: Re: [PATCH] media: videobuf2-dma-sg: limit the sg segment size
Date: Tue, 29 Aug 2023 12:14:44 +0100 [thread overview]
Message-ID: <deb735ce-7de1-e59a-9de4-1365b374b417@arm.com> (raw)
In-Reply-To: <CAAFQd5Cn3xQroyYtC+m+pk1jOE5i3H+FGr-y8zqhaf0Yo5p-1Q@mail.gmail.com>
On 2023-08-29 11:03, Tomasz Figa wrote:
> Hi Anle,
>
> On Mon, Aug 28, 2023 at 8:57 AM Anle Pan <anle.pan@nxp.com> wrote:
>>
>> When allocating from pages, the size of the sg segment is unlimited and
>> the default is UINT_MAX. This will cause the DMA stream mapping failed
>> later with a "swiotlb buffer full" error.
>
> Thanks for the patch. Good catch.
>
>> The default maximum mapping
>> size is 128 slots x 2K = 256K, determined by "IO_TLB_SEGSIZE".
>> To fix the issue, limit the sg segment size according to
>> "dma_max_mapping_size" to match the mapping limit.
>>
>> Signed-off-by: Anle Pan <anle.pan@nxp.com>
>> ---
>> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
>> index fa69158a65b1..b608a7c5f240 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
>> @@ -105,6 +105,7 @@ static void *vb2_dma_sg_alloc(struct vb2_buffer *vb, struct device *dev,
>> struct sg_table *sgt;
>> int ret;
>> int num_pages;
>> + size_t max_segment = 0;
>>
>> if (WARN_ON(!dev) || WARN_ON(!size))
>> return ERR_PTR(-EINVAL);
>> @@ -134,8 +135,12 @@ static void *vb2_dma_sg_alloc(struct vb2_buffer *vb, struct device *dev,
>> if (ret)
>> goto fail_pages_alloc;
>>
>> - ret = sg_alloc_table_from_pages(buf->dma_sgt, buf->pages,
>> - buf->num_pages, 0, size, GFP_KERNEL);
>> + if (dev)
dev can't be NULL, see the context above.
>> + max_segment = dma_max_mapping_size(dev);
>> + if (max_segment == 0)
>> + max_segment = UINT_MAX;
>> + ret = sg_alloc_table_from_pages_segment(buf->dma_sgt, buf->pages,
>> + buf->num_pages, 0, size, max_segment, GFP_KERNEL);
>
> One thing that I'm not sure about here is that we use
> sg_alloc_table_from_pages_segment(), but we actually don't pass the
> max segment size (as returned by dma_get_max_seg_size()) to it.
> I'm also not exactly sure what's the difference between "max mapping
> size" and "max seg size".
> +Robin Murphy +Christoph Hellwig I think we could benefit from your
> expertise here.
dma_get_max_seg_size() represents a capability of the device itself,
namely the largest contiguous range it can be programmed to access in a
single DMA descriptor/register/whatever. Conversely,
dma_max_mapping_size() is a capablity of the DMA API implementation, and
represents the largest contiguous mapping it is guaranteed to be able to
handle (each segment in the case of dma_map_sg(), or the whole thing for
dma_map_page()). Most likely the thing you want here is
min_not_zero(max_seg_size, max_mapping_size).
> Generally looking at videobuf2-dma-sg, I feel like we would benefit
> from some kind of dma_alloc_table_from_pages() that simply takes the
> struct dev pointer and does everything necessary.
Possibly; this code already looks lifted from drm_prime_pages_to_sg(),
and if it's needed here then presumably vb2_dma_sg_get_userptr() also
needs it, at the very least.
Thanks,
Robin.
next prev parent reply other threads:[~2023-08-29 11:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 7:54 [PATCH] media: videobuf2-dma-sg: limit the sg segment size Anle Pan
2023-08-29 10:03 ` Tomasz Figa
2023-08-29 11:14 ` Robin Murphy [this message]
2023-08-29 15:04 ` Christoph Hellwig
2023-08-30 3:47 ` Tomasz Figa
2023-08-30 14:33 ` Christoph Hellwig
2023-08-30 16:43 ` Jason Gunthorpe
2023-08-31 12:35 ` Christoph Hellwig
2023-08-31 15:32 ` Jason Gunthorpe
2023-09-01 6:10 ` Christoph Hellwig
2023-09-01 14:26 ` Jason Gunthorpe
[not found] ` <DB9PR04MB92841D8BC1122D5A4210F78987E6A@DB9PR04MB9284.eurprd04.prod.outlook.com>
2023-08-30 13:41 ` [EXT] " Robin Murphy
2023-08-30 3:59 ` Tomasz Figa
2023-09-06 8:52 ` Hans Verkuil
2023-09-06 9:26 ` Tomasz Figa
2023-09-06 9:43 ` Hans Verkuil
2023-08-30 8:50 ` Hui Fang
2023-08-30 9:28 ` Tomasz Figa
2023-09-04 7:10 ` [EXT] " Hui Fang
2023-09-05 3:43 ` Tomasz Figa
2023-09-06 8:16 ` Hui Fang
2023-09-06 9:28 ` Tomasz Figa
2023-09-11 6:13 ` Hui Fang
2023-09-12 2:22 ` Tomasz Figa
2023-09-12 7:01 ` Hui Fang
2023-09-12 7:10 ` Tomasz Figa
2023-09-12 7:43 ` Hui Fang
2023-09-12 7:51 ` Tomasz Figa
2023-09-13 9:13 ` Hui Fang
2023-09-13 9:44 ` Tomasz Figa
2023-09-13 13:16 ` Hui Fang
2023-09-18 2:28 ` Hui Fang
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=deb735ce-7de1-e59a-9de4-1365b374b417@arm.com \
--to=robin.murphy@arm.com \
--cc=anle.pan@nxp.com \
--cc=hch@lst.de \
--cc=hui.fang@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=tfiga@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.