dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Yong Wu <yong.wu@mediatek.com>, Rob Herring <robh+dt@kernel.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	christian.koenig@amd.com,
	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:12:17 -0400	[thread overview]
Message-ID: <827b859e3ff8176ef0b18c29bc17481b4105e368.camel@ndufresne.ca> (raw)
In-Reply-To: <20230911023038.30649-4-yong.wu@mediatek.com>

Hi,

Le lundi 11 septembre 2023 à 10:30 +0800, Yong Wu a écrit :
> 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.


Would be nice for the reviewers to provide the information about the user of
this new in-kernel API. I noticed it because I was CCed, but strangely it didn't
make it to the mailing list yet and its not clear in the cover what this is used
with. 

I can explain in my words though, my read is that this is used to allocate both
user visible and driver internal memory segments in MTK VCODEC driver.

I'm somewhat concerned that DMABuf objects are used to abstract secure memory
allocation from tee. For framebuffers that are going to be exported and shared
its probably fair use, but it seems that internal shared memory and codec
specific reference buffers also endup with a dmabuf fd (often called a secure fd
in the v4l2 patchset) for data that is not being shared, and requires a 1:1
mapping to a tee handle anyway. Is that the design we'd like to follow ? Can't
we directly allocate from the tee, adding needed helper to make this as simple
as allocating from a HEAP ?

Nicolas

> 
> 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 */


  parent reply	other threads:[~2023-09-11 16:12 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
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 [this message]
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=827b859e3ff8176ef0b18c29bc17481b4105e368.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.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).