[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB9PR04MB928460023FB3CCCBC3EACE1487E9A@DB9PR04MB9284.eurprd04.prod.outlook.com>
Date: Mon, 4 Sep 2023 07:10:08 +0000
From: Hui Fang <hui.fang@....com>
To: Tomasz Figa <tfiga@...omium.org>
CC: Anle Pan <anle.pan@....com>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jindong Yue <jindong.yue@....com>,
Xuegang Liu <xuegang.liu@....com>
Subject: RE: [EXT] Re: [PATCH] media: videobuf2-dma-sg: limit the sg segment
size
On Wed, Aug 30, 2023 at 6:20 PM Tomasz Figa <tfiga@...omium.org> wrote:
> On Wed, Aug 30, 2023 at 5:50 PM Hui Fang <hui.fang@....com> wrote:
......
> > I wonder if only NXP met the "swiotlb buffer full" issue. In theory,
> > when format is YUYV, those resolutions no greater than 320x240 (153600
> > bytes, which less than the max mapping size 256K ) can't meet the issue.
> > But resolutions no less than 640x480 (307200 bytes), may have chances
> > to trigger the issue.
>
> I think a combination of a device that can support scatter-gather, but requires
> swiotlb is kind of rare. Most drivers would require a single contiguous DMA
> address (and thus use videobuf2-dma-contig) and physical discontinuity would
> be handled by an IOMMU (transparently to vb2).
>
> I guess one thing to ask you about your specific setup is whether it's expected
> that the swiotlb ends up being used at all?
Yes, the swiotlb ends up being used. We met the issue when bring up
DeviceAsWebCam (android-14 new feature, android device works as a usb camera).
BRs,
Fang Hui
Powered by blists - more mailing lists