dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Yong Wu <yong.wu@mediatek.com>, Rob Herring <robh+dt@kernel.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>
Cc: devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, tjmercier@google.com,
	linaro-mm-sig@lists.linaro.org, John Stultz <jstultz@google.com>,
	jianjiao.zeng@mediatek.com,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH 3/9] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps
Date: Mon, 11 Sep 2023 12:13:47 +0200	[thread overview]
Message-ID: <803846bc-fd1d-d2ec-2855-456af22c82f8@amd.com> (raw)
In-Reply-To: <20230911023038.30649-4-yong.wu@mediatek.com>

Am 11.09.23 um 04:30 schrieb Yong Wu:
> From: John Stultz <jstultz@google.com>
>
> This allows drivers who don't want to create their own
> DMA-BUF exporter to be able to allocate DMA-BUFs directly
> from existing DMA-BUF Heaps.
>
> There is some concern that the premise of DMA-BUF heaps is
> that userland knows better about what type of heap memory
> is needed for a pipeline, so it would likely be best for
> drivers to import and fill DMA-BUFs allocated by userland
> instead of allocating one themselves, but this is still
> up for debate.

The main design goal of having DMA-heaps in the first place is to avoid 
per driver allocation and this is not necessary because userland know 
better what type of memory it wants.

The background is rather that we generally want to decouple allocation 
from having a device driver connection so that we have better chance 
that multiple devices can work with the same memory.

I once create a prototype which gives userspace a hint which DMA-heap to 
user for which device: 
https://patchwork.kernel.org/project/linux-media/patch/20230123123756.401692-2-christian.koenig@amd.com/

Problem is that I don't really have time to look into it and maintain 
that stuff, but I think from the high level design that is rather the 
general direction we should push at.

Regards,
Christian.

>
> Signed-off-by: John Stultz <jstultz@google.com>
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> [Yong: Fix the checkpatch alignment warning]
> ---
>   drivers/dma-buf/dma-heap.c | 60 ++++++++++++++++++++++++++++----------
>   include/linux/dma-heap.h   | 25 ++++++++++++++++
>   2 files changed, 69 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index dcc0e38c61fa..908bb30dc864 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -53,12 +53,15 @@ static dev_t dma_heap_devt;
>   static struct class *dma_heap_class;
>   static DEFINE_XARRAY_ALLOC(dma_heap_minors);
>   
> -static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> -				 unsigned int fd_flags,
> -				 unsigned int heap_flags)
> +struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> +				      unsigned int fd_flags,
> +				      unsigned int heap_flags)
>   {
> -	struct dma_buf *dmabuf;
> -	int fd;
> +	if (fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
> +		return ERR_PTR(-EINVAL);
>   
>   	/*
>   	 * Allocations from all heaps have to begin
> @@ -66,9 +69,20 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>   	 */
>   	len = PAGE_ALIGN(len);
>   	if (!len)
> -		return -EINVAL;
> +		return ERR_PTR(-EINVAL);
>   
> -	dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
> +	return heap->ops->allocate(heap, len, fd_flags, heap_flags);
> +}
> +EXPORT_SYMBOL_GPL(dma_heap_buffer_alloc);
> +
> +static int dma_heap_bufferfd_alloc(struct dma_heap *heap, size_t len,
> +				   unsigned int fd_flags,
> +				   unsigned int heap_flags)
> +{
> +	struct dma_buf *dmabuf;
> +	int fd;
> +
> +	dmabuf = dma_heap_buffer_alloc(heap, len, fd_flags, heap_flags);
>   	if (IS_ERR(dmabuf))
>   		return PTR_ERR(dmabuf);
>   
> @@ -106,15 +120,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
>   	if (heap_allocation->fd)
>   		return -EINVAL;
>   
> -	if (heap_allocation->fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
> -		return -EINVAL;
> -
> -	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
> -		return -EINVAL;
> -
> -	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
> -				   heap_allocation->fd_flags,
> -				   heap_allocation->heap_flags);
> +	fd = dma_heap_bufferfd_alloc(heap, heap_allocation->len,
> +				     heap_allocation->fd_flags,
> +				     heap_allocation->heap_flags);
>   	if (fd < 0)
>   		return fd;
>   
> @@ -205,6 +213,7 @@ const char *dma_heap_get_name(struct dma_heap *heap)
>   {
>   	return heap->name;
>   }
> +EXPORT_SYMBOL_GPL(dma_heap_get_name);
>   
>   struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
>   {
> @@ -290,6 +299,24 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
>   	kfree(heap);
>   	return err_ret;
>   }
> +EXPORT_SYMBOL_GPL(dma_heap_add);
> +
> +struct dma_heap *dma_heap_find(const char *name)
> +{
> +	struct dma_heap *h;
> +
> +	mutex_lock(&heap_list_lock);
> +	list_for_each_entry(h, &heap_list, list) {
> +		if (!strcmp(h->name, name)) {
> +			kref_get(&h->refcount);
> +			mutex_unlock(&heap_list_lock);
> +			return h;
> +		}
> +	}
> +	mutex_unlock(&heap_list_lock);
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(dma_heap_find);
>   
>   static void dma_heap_release(struct kref *ref)
>   {
> @@ -315,6 +342,7 @@ void dma_heap_put(struct dma_heap *h)
>   	kref_put(&h->refcount, dma_heap_release);
>   	mutex_unlock(&heap_list_lock);
>   }
> +EXPORT_SYMBOL_GPL(dma_heap_put);
>   
>   static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
>   {
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index f3c678892c5c..59e70f6c7a60 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -64,10 +64,35 @@ const char *dma_heap_get_name(struct dma_heap *heap);
>    */
>   struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>   
> +/**
> + * dma_heap_find - get the heap registered with the specified name
> + * @name: Name of the DMA-Heap to find
> + *
> + * Returns:
> + * The DMA-Heap with the provided name.
> + *
> + * NOTE: DMA-Heaps returned from this function MUST be released using
> + * dma_heap_put() when the user is done to enable the heap to be unloaded.
> + */
> +struct dma_heap *dma_heap_find(const char *name);
> +
>   /**
>    * dma_heap_put - drops a reference to a dmabuf heap, potentially freeing it
>    * @heap: the heap whose reference count to decrement
>    */
>   void dma_heap_put(struct dma_heap *heap);
>   
> +/**
> + * dma_heap_buffer_alloc - Allocate dma-buf from a dma_heap
> + * @heap:	DMA-Heap to allocate from
> + * @len:	size to allocate in bytes
> + * @fd_flags:	flags to set on returned dma-buf fd
> + * @heap_flags: flags to pass to the dma heap
> + *
> + * This is for internal dma-buf allocations only. Free returned buffers with dma_buf_put().
> + */
> +struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> +				      unsigned int fd_flags,
> +				      unsigned int heap_flags);
> +
>   #endif /* _DMA_HEAPS_H */


  reply	other threads:[~2023-09-11 10:14 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11  2:30 [PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap Yong Wu
2023-09-11  2:30 ` [PATCH 1/9] dma-buf: heaps: Deduplicate docs and adopt common format Yong Wu
2023-09-11  9:36   ` Christian König
2023-09-11 23:51     ` T.J. Mercier
2023-09-11  2:30 ` [PATCH 2/9] dma-heap: Add proper kref handling on dma-buf heaps Yong Wu
2023-09-11  9:48   ` Christian König
2023-09-22 18:19     ` T.J. Mercier
2023-09-11  2:30 ` [PATCH 3/9] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps Yong Wu
2023-09-11 10:13   ` Christian König [this message]
2023-09-11 18:29     ` John Stultz
2023-09-12  7:06       ` Christian König
2023-09-12  8:52         ` Yong Wu (吴勇)
2023-09-12 14:46           ` Christian König
2023-09-12 14:58             ` Nicolas Dufresne
2023-09-13  8:30               ` Christian König
2023-09-12 14:50     ` Nicolas Dufresne
2023-09-11 16:12   ` Nicolas Dufresne
2023-09-12  8:47     ` Yong Wu (吴勇)
2023-09-12 15:05       ` Nicolas Dufresne
2023-09-18 10:46         ` Yong Wu (吴勇)
2023-09-11  2:30 ` [PATCH 4/9] dma-buf: heaps: Initialise MediaTek secure heap Yong Wu
2023-09-11  8:05   ` kernel test robot
2023-09-27 14:42   ` Joakim Bech
2023-09-28  8:03     ` Yong Wu (吴勇)
2023-10-19  4:45   ` Vijayanand Jitta
2023-10-20  9:59     ` Yong Wu (吴勇)
2023-10-26  4:48       ` Vijayanand Jitta
2023-10-27  7:47         ` Yong Wu (吴勇)
2023-10-30  8:06           ` Vijayanand Jitta
2023-09-11  2:30 ` [PATCH 5/9] dma-buf: heaps: mtk_sec_heap: Initialise tee session Yong Wu
2023-09-11  9:29   ` AngeloGioacchino Del Regno
2023-09-11 10:15     ` Christian König
2023-09-12  6:17     ` Yong Wu (吴勇)
2023-09-12  9:32       ` AngeloGioacchino Del Regno
2023-09-25 12:49         ` Yong Wu (吴勇)
2023-09-27 13:46           ` Joakim Bech
2023-09-27 15:17             ` Benjamin Gaignard
2023-09-27 18:56               ` Jeffrey Kardatzke
2023-09-28  8:30                 ` Benjamin Gaignard
2023-09-28 17:48                   ` Jeffrey Kardatzke
2023-09-29  6:54                     ` Benjamin Gaignard
2023-10-13 19:09                       ` Jeffrey Kardatzke
2023-10-13 19:10                       ` Jeffrey Kardatzke
2023-09-27 18:54             ` Jeffrey Kardatzke
2023-09-13 13:35   ` kernel test robot
2023-09-11  2:30 ` [PATCH 6/9] dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing Yong Wu
2023-09-14 10:18   ` kernel test robot
2023-09-27 14:37   ` Joakim Bech
2023-09-28  5:24     ` Yong Wu (吴勇)
2023-10-19  4:45   ` Vijayanand Jitta
2023-10-20 10:01     ` Yong Wu (吴勇)
2023-09-11  2:30 ` [PATCH 7/9] dma-buf: heaps: mtk_sec_heap: Add dma_ops Yong Wu
2023-09-11  2:30 ` [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP Yong Wu
2023-09-11 15:44   ` Rob Herring
2023-09-12  6:16     ` Yong Wu (吴勇)
2023-09-12  8:28       ` Krzysztof Kozlowski
2023-09-12 10:13         ` Robin Murphy
2023-09-12 15:53           ` Rob Herring
2023-09-12 16:05             ` Robin Murphy
2023-09-18 10:47             ` Yong Wu (吴勇)
2023-09-19 22:15               ` Jeffrey Kardatzke
2023-10-12  6:54                 ` Yong Wu (吴勇)
2023-10-12  7:07                   ` Krzysztof Kozlowski
2023-10-12 11:15                     ` Yong Wu (吴勇)
2023-10-19  4:46   ` Vijayanand Jitta
2023-10-20  9:50     ` Yong Wu (吴勇)
2023-11-01  5:50       ` Jaskaran Singh
2023-11-06  5:56         ` Yong Wu (吴勇)
2023-11-20  8:20           ` Jaskaran Singh
2023-09-11  2:30 ` [PATCH 9/9] dma_buf: heaps: mtk_sec_heap: Add a new CMA heap Yong Wu
2023-09-11  9:33   ` AngeloGioacchino Del Regno
2023-10-19  4:44 ` [PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap Vijayanand Jitta

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=803846bc-fd1d-d2ec-2855-456af22c82f8@amd.com \
    --to=christian.koenig@amd.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jianjiao.zeng@mediatek.com \
    --cc=jstultz@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    --cc=yong.wu@mediatek.com \
    /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).