linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Paul Cercueil" <paul@crapouillou.net>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sumit Semwal" <sumit.semwal@linaro.org>
Cc: "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,
	"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [Linaro-mm-sig] [PATCH v5 1/6] dma-buf: Add dma_buf_{begin,end}_access()
Date: Tue, 23 Jan 2024 12:52:21 +0100	[thread overview]
Message-ID: <85a89505-edeb-4619-86c1-157f7abdd190@amd.com> (raw)
In-Reply-To: <e4620acdf24628d904cedcb0030d78b14559f337.camel@crapouillou.net>

Am 23.01.24 um 11:10 schrieb Paul Cercueil:
> Hi Christian,
>
> Le lundi 22 janvier 2024 à 14:41 +0100, Christian König a écrit :
>> Am 22.01.24 um 12:01 schrieb Paul Cercueil:
>>> Hi Christian,
>>>
>>> Le lundi 22 janvier 2024 à 11:35 +0100, Christian König a écrit :
>>>> Am 19.01.24 um 15:13 schrieb Paul Cercueil:
>>>>> These functions should be used by device drivers when they
>>>>> start
>>>>> and
>>>>> stop accessing the data of DMABUF. It allows DMABUF importers
>>>>> to
>>>>> cache
>>>>> the dma_buf_attachment while ensuring that the data they want
>>>>> to
>>>>> access
>>>>> is available for their device when the DMA transfers take
>>>>> place.
>>>> As Daniel already noted as well this is a complete no-go from the
>>>> DMA-buf design point of view.
>>> What do you mean "as Daniel already noted"? It was him who
>>> suggested
>>> this.
>> Sorry, I haven't fully catched up to the discussion then.
>>
>> In general DMA-buf is build around the idea that the data can be
>> accessed coherently by the involved devices.
>>
>> Having a begin/end of access for devices was brought up multiple
>> times
>> but so far rejected for good reasons.
> I would argue that if it was brought up multiple times, then there are
> also good reasons to support such a mechanism.
>
>> That an exporter has to call extra functions to access his own
>> buffers
>> is a complete no-go for the design since this forces exporters into
>> doing extra steps for allowing importers to access their data.
> Then what about we add these dma_buf_{begin,end}_access(), with only
> implementations for "dumb" exporters e.g. udmabuf or the dmabuf heaps?
> And only importers (who cache the mapping and actually care about non-
> coherency) would have to call these.

No, the problem is still that you would have to change all importers to 
mandatory use dma_buf_begin/end.

But going a step back caching the mapping is irrelevant for coherency. 
Even if you don't cache the mapping you don't get coherency.

In other words exporters are not require to call sync_to_cpu or 
sync_to_device when you create a mapping.

What exactly is your use case here? And why does coherency matters?

> At the very least, is there a way to check that "the data can be
> accessed coherently by the involved devices"? So that my importer can
> EPERM if there is no coherency vs. a device that's already attached.

Yeah, there is functionality for this in the DMA subsystem. I've once 
created prototype patches for enforcing the same coherency approach 
between importer and exporter, but we never got around to upstream them.



>
> Cheers,
> -Paul
>
>> That in turn is pretty much un-testable unless you have every
>> possible
>> importer around while testing the exporter.
>>
>> Regards,
>> Christian.
>>
>>>> Regards,
>>>> Christian.
>>> Cheers,
>>> -Paul
>>>
>>>>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>>>>
>>>>> ---
>>>>> v5: New patch
>>>>> ---
>>>>>     drivers/dma-buf/dma-buf.c | 66
>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>     include/linux/dma-buf.h   | 37 ++++++++++++++++++++++
>>>>>     2 files changed, 103 insertions(+)
>>>>>
>>>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-
>>>>> buf.c
>>>>> index 8fe5aa67b167..a8bab6c18fcd 100644
>>>>> --- a/drivers/dma-buf/dma-buf.c
>>>>> +++ b/drivers/dma-buf/dma-buf.c
>>>>> @@ -830,6 +830,8 @@ static struct sg_table *
>>>>> __map_dma_buf(struct
>>>>> dma_buf_attachment *attach,
>>>>>      *     - dma_buf_mmap()
>>>>>      *     - dma_buf_begin_cpu_access()
>>>>>      *     - dma_buf_end_cpu_access()
>>>>> + *     - dma_buf_begin_access()
>>>>> + *     - dma_buf_end_access()
>>>>>      *     - dma_buf_map_attachment_unlocked()
>>>>>      *     - dma_buf_unmap_attachment_unlocked()
>>>>>      *     - dma_buf_vmap_unlocked()
>>>>> @@ -1602,6 +1604,70 @@ void dma_buf_vunmap_unlocked(struct
>>>>> dma_buf
>>>>> *dmabuf, struct iosys_map *map)
>>>>>     }
>>>>>     EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
>>>>>     
>>>>> +/**
>>>>> + * @dma_buf_begin_access - Call before any hardware access
>>>>> from/to
>>>>> the DMABUF
>>>>> + * @attach:	[in]	attachment used for hardware access
>>>>> + * @sg_table:	[in]	scatterlist used for the DMA transfer
>>>>> + * @direction:  [in]    direction of DMA transfer
>>>>> + */
>>>>> +int dma_buf_begin_access(struct dma_buf_attachment *attach,
>>>>> +			 struct sg_table *sgt, enum
>>>>> dma_data_direction dir)
>>>>> +{
>>>>> +	struct dma_buf *dmabuf;
>>>>> +	bool cookie;
>>>>> +	int ret;
>>>>> +
>>>>> +	if (WARN_ON(!attach))
>>>>> +		return -EINVAL;
>>>>> +
>>>>> +	dmabuf = attach->dmabuf;
>>>>> +
>>>>> +	if (!dmabuf->ops->begin_access)
>>>>> +		return 0;
>>>>> +
>>>>> +	cookie = dma_fence_begin_signalling();
>>>>> +	ret = dmabuf->ops->begin_access(attach, sgt, dir);
>>>>> +	dma_fence_end_signalling(cookie);
>>>>> +
>>>>> +	if (WARN_ON_ONCE(ret))
>>>>> +		return ret;
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL_NS_GPL(dma_buf_begin_access, DMA_BUF);
>>>>> +
>>>>> +/**
>>>>> + * @dma_buf_end_access - Call after any hardware access
>>>>> from/to
>>>>> the DMABUF
>>>>> + * @attach:	[in]	attachment used for hardware access
>>>>> + * @sg_table:	[in]	scatterlist used for the DMA transfer
>>>>> + * @direction:  [in]    direction of DMA transfer
>>>>> + */
>>>>> +int dma_buf_end_access(struct dma_buf_attachment *attach,
>>>>> +		       struct sg_table *sgt, enum
>>>>> dma_data_direction dir)
>>>>> +{
>>>>> +	struct dma_buf *dmabuf;
>>>>> +	bool cookie;
>>>>> +	int ret;
>>>>> +
>>>>> +	if (WARN_ON(!attach))
>>>>> +		return -EINVAL;
>>>>> +
>>>>> +	dmabuf = attach->dmabuf;
>>>>> +
>>>>> +	if (!dmabuf->ops->end_access)
>>>>> +		return 0;
>>>>> +
>>>>> +	cookie = dma_fence_begin_signalling();
>>>>> +	ret = dmabuf->ops->end_access(attach, sgt, dir);
>>>>> +	dma_fence_end_signalling(cookie);
>>>>> +
>>>>> +	if (WARN_ON_ONCE(ret))
>>>>> +		return ret;
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL_NS_GPL(dma_buf_end_access, DMA_BUF);
>>>>> +
>>>>>     #ifdef CONFIG_DEBUG_FS
>>>>>     static int dma_buf_debug_show(struct seq_file *s, void
>>>>> *unused)
>>>>>     {
>>>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>>>>> index 8ff4add71f88..8ba612c7cc16 100644
>>>>> --- a/include/linux/dma-buf.h
>>>>> +++ b/include/linux/dma-buf.h
>>>>> @@ -246,6 +246,38 @@ struct dma_buf_ops {
>>>>>     	 */
>>>>>     	int (*end_cpu_access)(struct dma_buf *, enum
>>>>> dma_data_direction);
>>>>>     
>>>>> +	/**
>>>>> +	 * @begin_access:
>>>>> +	 *
>>>>> +	 * This is called from dma_buf_begin_access() when a
>>>>> device driver
>>>>> +	 * wants to access the data of the DMABUF. The
>>>>> exporter
>>>>> can use this
>>>>> +	 * to flush/sync the caches if needed.
>>>>> +	 *
>>>>> +	 * This callback is optional.
>>>>> +	 *
>>>>> +	 * Returns:
>>>>> +	 *
>>>>> +	 * 0 on success or a negative error code on failure.
>>>>> +	 */
>>>>> +	int (*begin_access)(struct dma_buf_attachment *,
>>>>> struct
>>>>> sg_table *,
>>>>> +			    enum dma_data_direction);
>>>>> +
>>>>> +	/**
>>>>> +	 * @end_access:
>>>>> +	 *
>>>>> +	 * This is called from dma_buf_end_access() when a
>>>>> device
>>>>> driver is
>>>>> +	 * done accessing the data of the DMABUF. The exporter
>>>>> can
>>>>> use this
>>>>> +	 * to flush/sync the caches if needed.
>>>>> +	 *
>>>>> +	 * This callback is optional.
>>>>> +	 *
>>>>> +	 * Returns:
>>>>> +	 *
>>>>> +	 * 0 on success or a negative error code on failure.
>>>>> +	 */
>>>>> +	int (*end_access)(struct dma_buf_attachment *, struct
>>>>> sg_table *,
>>>>> +			  enum dma_data_direction);
>>>>> +
>>>>>     	/**
>>>>>     	 * @mmap:
>>>>>     	 *
>>>>> @@ -606,6 +638,11 @@ void dma_buf_detach(struct dma_buf
>>>>> *dmabuf,
>>>>>     int dma_buf_pin(struct dma_buf_attachment *attach);
>>>>>     void dma_buf_unpin(struct dma_buf_attachment *attach);
>>>>>     
>>>>> +int dma_buf_begin_access(struct dma_buf_attachment *attach,
>>>>> +			 struct sg_table *sgt, enum
>>>>> dma_data_direction dir);
>>>>> +int dma_buf_end_access(struct dma_buf_attachment *attach,
>>>>> +		       struct sg_table *sgt, enum
>>>>> dma_data_direction dir);
>>>>> +
>>>>>     struct dma_buf *dma_buf_export(const struct
>>>>> dma_buf_export_info
>>>>> *exp_info);
>>>>>     
>>>>>     int dma_buf_fd(struct dma_buf *dmabuf, int flags);


  reply	other threads:[~2024-01-23 11:52 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 [this message]
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   ` [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=85a89505-edeb-4619-86c1-157f7abdd190@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --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).