linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Paul Cercueil <paul@crapouillou.net>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"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
Subject: Re: [Linaro-mm-sig] [PATCH v5 2/6] dma-buf: udmabuf: Implement .{begin,end}_access
Date: Wed, 7 Feb 2024 18:10:09 +0100	[thread overview]
Message-ID: <ZcO5ccqwTIhSKDfS@phenom.ffwll.local> (raw)
In-Reply-To: <20240119141402.44262-3-paul@crapouillou.net>

On Fri, Jan 19, 2024 at 03:13:58PM +0100, Paul Cercueil wrote:
> Implement .begin_access() and .end_access() callbacks.
> 
> For now these functions will simply sync/flush the CPU cache when
> needed.
> 
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> 
> ---
> v5: New patch
> ---
>  drivers/dma-buf/udmabuf.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index c40645999648..a87d89b58816 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -179,6 +179,31 @@ static int end_cpu_udmabuf(struct dma_buf *buf,
>  	return 0;
>  }
>  
> +static int begin_udmabuf(struct dma_buf_attachment *attach,
> +			 struct sg_table *sgt,
> +			 enum dma_data_direction dir)
> +{
> +	struct dma_buf *buf = attach->dmabuf;
> +	struct udmabuf *ubuf = buf->priv;
> +	struct device *dev = ubuf->device->this_device;
> +
> +	dma_sync_sg_for_device(dev, sgt->sgl, sg_nents(sgt->sgl), dir);

So one thing I've just wondered is whether we've made sure that this is
only doing cache coherency maintenance, and not swiotlb bounce buffer
copying. The latter would really not be suitable for dma-buf anymore I
think.

Not sure how to best check for that since it's all in the depths of the
dma-api code, but I guess the best way to really make sure is to disable
CONFIG_SWIOTLB. Otherwise I guess the way to absolutely make sure is to
trace swiotlb_sync_single_for_device/cpu.

It would be kinda neat if dma-buf.c code could make sure you never ever
get an swiotlb entry from a dma_buf_map_attachment call, but I don't think
we can enforce that. There's sg_dma_is_swiotlb, but that won't catch all
implementations, only the generic dma-iommu.c one.

Cheers, Sima

> +	return 0;
> +}
> +
> +static int end_udmabuf(struct dma_buf_attachment *attach,
> +		       struct sg_table *sgt,
> +		       enum dma_data_direction dir)
> +{
> +	struct dma_buf *buf = attach->dmabuf;
> +	struct udmabuf *ubuf = buf->priv;
> +	struct device *dev = ubuf->device->this_device;
> +
> +	if (dir != DMA_TO_DEVICE)
> +		dma_sync_sg_for_cpu(dev, sgt->sgl, sg_nents(sgt->sgl), dir);
> +	return 0;
> +}
> +
>  static const struct dma_buf_ops udmabuf_ops = {
>  	.cache_sgt_mapping = true,
>  	.map_dma_buf	   = map_udmabuf,
> @@ -189,6 +214,8 @@ static const struct dma_buf_ops udmabuf_ops = {
>  	.vunmap		   = vunmap_udmabuf,
>  	.begin_cpu_access  = begin_cpu_udmabuf,
>  	.end_cpu_access    = end_cpu_udmabuf,
> +	.begin_access      = begin_udmabuf,
> +	.end_access        = end_udmabuf,
>  };
>  
>  #define SEALS_WANTED (F_SEAL_SHRINK)
> -- 
> 2.43.0
> 
> _______________________________________________
> Linaro-mm-sig mailing list -- linaro-mm-sig@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-leave@lists.linaro.org

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2024-02-07 17:10 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
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   ` Daniel Vetter [this message]
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=ZcO5ccqwTIhSKDfS@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Michael.Hennerich@analog.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).