From: Daniel Vetter <daniel@ffwll.ch>
To: Paul Cercueil <paul@crapouillou.net>
Cc: "Christian König" <christian.koenig@amd.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Nuno Sá" <noname.nuno@gmail.com>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
linux-usb@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [Linaro-mm-sig] Re: [PATCH v5 1/6] dma-buf: Add dma_buf_{begin,end}_access()
Date: Tue, 30 Jan 2024 11:40:38 +0100 [thread overview]
Message-ID: <ZbjSJi07gQhZ4WMC@phenom.ffwll.local> (raw)
In-Reply-To: <7eec45a95808afe94ac65a8518df853356ecf117.camel@crapouillou.net>
On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
> Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
> > I would say we start with the DMA-API by getting away from sg_tables
> > to something cleaner and state oriented.
>
> FYI I am already adding a 'dma_vec' object in my IIO DMABUF patchset,
> which is just a dead simple
>
> struct dma_vec {
> dma_addr_t addr;
> size_t len;
> };
>
> (The rationale for introducing it in the IIO DMABUF patchset was that
> the "scatterlist" wouldn't allow me to change the transfer size.)
>
> So I believe a new "sg_table"-like could just be an array of struct
> dma_vec + flags.
Yeah that's pretty much the proposal I've seen, split the sg table into
input data (struct page + len) and output data (which is the dma_addr_t +
len you have above).
The part I don't expect to ever happen, because it hasn't the past 20 or
so years, is that the dma-api will give us information about what is
needed to keep the buffers coherency between various devices and the cpu.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-01-30 10:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 14:13 [PATCH v5 0/6] usb: gadget: functionfs: DMABUF import interface Paul Cercueil
2024-01-19 14:13 ` [PATCH v5 1/6] dma-buf: Add dma_buf_{begin,end}_access() Paul Cercueil
2024-01-20 20:20 ` kernel test robot
2024-01-22 10:35 ` [Linaro-mm-sig] " Christian König
2024-01-22 11:01 ` Paul Cercueil
2024-01-22 13:41 ` Christian König
2024-01-23 10:10 ` Paul Cercueil
2024-01-23 11:52 ` Christian König
2024-01-23 13:02 ` Paul Cercueil
[not found] ` <577501f9-9d1c-4f8d-9882-7c71090e5ef3@amd.com>
2024-01-24 10:58 ` Paul Cercueil
2024-01-24 15:38 ` Andrew Davis
2024-01-24 15:52 ` Paul Cercueil
[not found] ` <2ac7562c-d221-409a-bfee-1b3cfcc0f1c6@amd.com>
2024-01-25 18:01 ` Daniel Vetter
2024-01-26 16:42 ` Christian König
2024-01-30 9:01 ` [Linaro-mm-sig] " Daniel Vetter
[not found] ` <a2346244-e22b-4ff6-b6cd-1da7138725ae@amd.com>
2024-01-30 9:48 ` Paul Cercueil
2024-01-30 10:40 ` Daniel Vetter [this message]
2024-01-30 13:09 ` Christian König
2024-01-31 9:07 ` Daniel Vetter
2024-02-06 13:28 ` Christian König
2024-02-06 13:57 ` Daniel Vetter
2024-01-30 10:38 ` Daniel Vetter
2024-01-25 18:10 ` Daniel Vetter
2024-01-19 14:13 ` [PATCH v5 2/6] dma-buf: udmabuf: Implement .{begin,end}_access Paul Cercueil
2024-02-07 17:10 ` [Linaro-mm-sig] " Daniel Vetter
2024-01-19 14:13 ` [PATCH v5 3/6] usb: gadget: Support already-mapped DMA SGs Paul Cercueil
2024-01-19 14:14 ` [PATCH v5 4/6] usb: gadget: functionfs: Factorize wait-for-endpoint code Paul Cercueil
2024-01-19 14:14 ` [PATCH v5 5/6] usb: gadget: functionfs: Add DMABUF import interface Paul Cercueil
2024-01-19 14:14 ` [PATCH v5 6/6] Documentation: usb: Document FunctionFS DMABUF API Paul Cercueil
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=ZbjSJi07gQhZ4WMC@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Michael.Hennerich@analog.com \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=jic23@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=noname.nuno@gmail.com \
--cc=paul@crapouillou.net \
--cc=sumit.semwal@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox