From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Christoph Hellwig <hch@lst.de>, Tomasz Figa <tfiga@chromium.org>,
Robin Murphy <robin.murphy@arm.com>, Anle Pan <anle.pan@nxp.com>,
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: Thu, 31 Aug 2023 14:35:32 +0200 [thread overview]
Message-ID: <20230831123532.GA11156@lst.de> (raw)
In-Reply-To: <ZO9xzf727b/YvZB/@ziepe.ca>
On Wed, Aug 30, 2023 at 01:43:57PM -0300, Jason Gunthorpe wrote:
> > > conversion function for the drivers.
> >
> > Jason said at LSF/MM that he had a prototype for a mapping API that
> > takes a phys/len array as input and dma_addr/len a output, which really
> > is the right thing to do, especially for dmabuf.
>
> Yes, still a prototype. Given the change in direction some of the
> assumptions of the list design will need some adjusting.
>
> I felt there wasn't much justification to add a list without also
> supporting the P2P and it was not looking very good to give the DMA
> API proper p2p support without also connecting it to lists somehow.
>
> Anyhow, I had drafted a basic list datastructure and starting
> implementation that is sort of structured in away that is similar to
> xarray (eg with fixed chunks, generic purpose, etc)
>
> https://github.com/jgunthorpe/linux/commit/58d7e0578a09d9cd2360be515208bcd74ade5958
This seems fairly complicated complicated, and the entry seems pretty large
for a bio_vec replacement or a dma_addr_t+len tuple, which both should
be (sizeof(phys_addr_t) + sizeof(u32) + the size of flags if needed, which
for 64-bit would fit into the padding from 96 bytes to 128 bytes anyway.
next prev parent reply other threads:[~2023-08-31 12:35 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
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 [this message]
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=20230831123532.GA11156@lst.de \
--to=hch@lst.de \
--cc=anle.pan@nxp.com \
--cc=hui.fang@nxp.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=robin.murphy@arm.com \
--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.