[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAFQd5DHUU4zb-J2MvtDXohwKttR_i9_C68RPjn82MFVEsjopw@mail.gmail.com>
Date: Wed, 30 Aug 2023 12:59:41 +0900
From: Tomasz Figa <tfiga@...omium.org>
To: Robin Murphy <robin.murphy@....com>
Cc: Anle Pan <anle.pan@....com>, Christoph Hellwig <hch@....de>,
m.szyprowski@...sung.com, mchehab@...nel.org,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
hui.fang@....com
Subject: Re: [PATCH] media: videobuf2-dma-sg: limit the sg segment size
On Tue, Aug 29, 2023 at 8:14 PM Robin Murphy <robin.murphy@....com> wrote:
>
> On 2023-08-29 11:03, Tomasz Figa wrote:
> > Hi Anle,
> >
> > On Mon, Aug 28, 2023 at 8:57 AM Anle Pan <anle.pan@....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@....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).
>
The extra complexity needed here convinces me even more that we need a helper...
> > 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.
That code probably predates drm_prime_pages_to_sg(), but that's
probably also the reason that it has its own issues...
I'm tempted to send a patch adding such a helper, but Christoph didn't
sound very keen on that idea. Hmm.
Best regards,
Tomasz
Powered by blists - more mailing lists