Linux-Media Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
@ 2020-07-17  1:10 Kunihiko Hayashi
  2020-07-28 19:17 ` John Stultz
  0 siblings, 1 reply; 4+ messages in thread
From: Kunihiko Hayashi @ 2020-07-17  1:10 UTC (permalink / raw)
  To: Sumit Semwal, Andrew F . Davis, Benjamin Gaignard, Liam Mark,
	Laura Abbott, Brian Starkey, John Stultz, Christian Koenig
  Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, Kunihiko Hayashi

Current dma-buf heaps can handle only default CMA. This introduces
dma_heap_add_cma() function to attach CMA heaps that belongs to a device.

At first, the driver calls of_reserved_mem_device_init() to set
memory-region property associated with reserved-memory defined as CMA
to the device. And when the driver calls this dma_heap_add_cma(),
the CMA will be added to dma-buf heaps.

For example, prepare CMA node named "linux,cma@10000000" and
specify the node for memory-region property. After the above calls
in the driver, a device file "/dev/dma_heap/linux,cma@10000000"
associated with the CMA become available as dma-buf heaps.

Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
 drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++++
 include/linux/dma-heap.h         |  9 +++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7f..5d2442e 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -162,6 +162,18 @@ static int __add_cma_heap(struct cma *cma, void *data)
 	return 0;
 }
 
+/* add device CMA heap to dmabuf heaps */
+int dma_heap_add_cma(struct device *dev)
+{
+	struct cma *cma = dev_get_cma_area(dev);
+
+	if (!cma)
+		return -ENOMEM;
+
+	return __add_cma_heap(cma, NULL);
+}
+EXPORT_SYMBOL_GPL(dma_heap_add_cma);
+
 static int add_default_cma_heap(void)
 {
 	struct cma *default_cma = dev_get_cma_area(NULL);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354..16bec7d 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -56,4 +56,13 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+#ifdef CONFIG_DMABUF_HEAPS_CMA
+/**
+ * dma_heap_add_cma - adds a device CMA heap to dmabuf heaps
+ * @dev:	device with a CMA heap to register
+ */
+int dma_heap_add_cma(struct device *dev);
+
+#endif /* CONFIG_DMABUF_HEAPS_CMA */
+
 #endif /* _DMA_HEAPS_H */
-- 
2.7.4


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
  2020-07-17  1:10 [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap Kunihiko Hayashi
@ 2020-07-28 19:17 ` John Stultz
  2020-07-31  9:32   ` Kunihiko Hayashi
  0 siblings, 1 reply; 4+ messages in thread
From: John Stultz @ 2020-07-28 19:17 UTC (permalink / raw)
  To: Kunihiko Hayashi
  Cc: Sumit Semwal, Andrew F . Davis, Benjamin Gaignard, Liam Mark,
	Laura Abbott, Brian Starkey, Christian Koenig, linux-media,
	dri-devel, moderated list:DMA BUFFER SHARING FRAMEWORK, lkml

On Thu, Jul 16, 2020 at 6:10 PM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
>
> Current dma-buf heaps can handle only default CMA. This introduces
> dma_heap_add_cma() function to attach CMA heaps that belongs to a device.
>
> At first, the driver calls of_reserved_mem_device_init() to set
> memory-region property associated with reserved-memory defined as CMA
> to the device. And when the driver calls this dma_heap_add_cma(),
> the CMA will be added to dma-buf heaps.
>
> For example, prepare CMA node named "linux,cma@10000000" and
> specify the node for memory-region property. After the above calls
> in the driver, a device file "/dev/dma_heap/linux,cma@10000000"
> associated with the CMA become available as dma-buf heaps.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
>  drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++++
>  include/linux/dma-heap.h         |  9 +++++++++
>  2 files changed, 21 insertions(+)

Hey! Sorry for the slow response on this! I just realized I never replied!

> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
> index 626cf7f..5d2442e 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -162,6 +162,18 @@ static int __add_cma_heap(struct cma *cma, void *data)
>         return 0;
>  }
>
> +/* add device CMA heap to dmabuf heaps */
> +int dma_heap_add_cma(struct device *dev)
> +{
> +       struct cma *cma = dev_get_cma_area(dev);
> +
> +       if (!cma)
> +               return -ENOMEM;
> +
> +       return __add_cma_heap(cma, NULL);
> +}
> +EXPORT_SYMBOL_GPL(dma_heap_add_cma);
> +
>  static int add_default_cma_heap(void)
>  {
>         struct cma *default_cma = dev_get_cma_area(NULL);
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index 454e354..16bec7d 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -56,4 +56,13 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
>   */
>  struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>
> +#ifdef CONFIG_DMABUF_HEAPS_CMA
> +/**
> + * dma_heap_add_cma - adds a device CMA heap to dmabuf heaps
> + * @dev:       device with a CMA heap to register
> + */
> +int dma_heap_add_cma(struct device *dev);
> +
> +#endif /* CONFIG_DMABUF_HEAPS_CMA */
> +
>  #endif /* _DMA_HEAPS_H */
> --
> 2.7.4

Looks sane to me.  Being able to expose different multiple CMA heaps
is needed, and I agree this way (as opposed to my earlier dts
appraoch) is probably the best approach. The only bit I'm so-so on is
adding the CMA heap specific call in the dma-heap.h, but at the same
time I can't justify adding a whole new header for a single function.

Do you have a upstream driver that you plan to make use this new call?
We want to have in-tree users of code added.

But if so, feel free to add my:
  Acked-by: John Stultz <john.stultz@linaro.org>
To this patch when you submit the driver changes.

thanks
-john

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
  2020-07-28 19:17 ` John Stultz
@ 2020-07-31  9:32   ` Kunihiko Hayashi
  2020-07-31 19:38     ` John Stultz
  0 siblings, 1 reply; 4+ messages in thread
From: Kunihiko Hayashi @ 2020-07-31  9:32 UTC (permalink / raw)
  To: John Stultz
  Cc: Sumit Semwal, Andrew F . Davis, Benjamin Gaignard, Liam Mark,
	Laura Abbott, Brian Starkey, Christian Koenig, linux-media,
	dri-devel, moderated list:DMA BUFFER SHARING FRAMEWORK, lkml

Hi John,
Thank you for your comment.

On 2020/07/29 4:17, John Stultz wrote:
> On Thu, Jul 16, 2020 at 6:10 PM Kunihiko Hayashi
> <hayashi.kunihiko@socionext.com> wrote:
>>
>> Current dma-buf heaps can handle only default CMA. This introduces
>> dma_heap_add_cma() function to attach CMA heaps that belongs to a device.
>>
>> At first, the driver calls of_reserved_mem_device_init() to set
>> memory-region property associated with reserved-memory defined as CMA
>> to the device. And when the driver calls this dma_heap_add_cma(),
>> the CMA will be added to dma-buf heaps.
>>
>> For example, prepare CMA node named "linux,cma@10000000" and
>> specify the node for memory-region property. After the above calls
>> in the driver, a device file "/dev/dma_heap/linux,cma@10000000"
>> associated with the CMA become available as dma-buf heaps.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>>   drivers/dma-buf/heaps/cma_heap.c | 12 ++++++++++++
>>   include/linux/dma-heap.h         |  9 +++++++++
>>   2 files changed, 21 insertions(+)
> 
> Hey! Sorry for the slow response on this! I just realized I never replied!

I waited but no problem.

> 
>> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
>> index 626cf7f..5d2442e 100644
>> --- a/drivers/dma-buf/heaps/cma_heap.c
>> +++ b/drivers/dma-buf/heaps/cma_heap.c

[snip]

>> --
>> 2.7.4
> 
> Looks sane to me.  Being able to expose different multiple CMA heaps
> is needed, and I agree this way (as opposed to my earlier dts
> appraoch) is probably the best approach. The only bit I'm so-so on is
> adding the CMA heap specific call in the dma-heap.h, but at the same
> time I can't justify adding a whole new header for a single function.

I'm also a little worried about whether "CMA specific" call is in
the dma-heap.h, however I can't find another solution.

> Do you have a upstream driver that you plan to make use this new call?

Unfortunately I don't have an upstream driver using this call.

This call is called from dma-buf heaps "importer" or "customer",
and I only made an example (do nothing) importer driver
to test the call.

> We want to have in-tree users of code added.

I think this is a generic way to use non-default CMA heaps, however,
we need in-tree "importer" drivers to want to use non-default CMA heaps.
I don't find it from now.

> But if so, feel free to add my:
>    Acked-by: John Stultz <john.stultz@linaro.org>
> To this patch when you submit the driver changes.

Thank you,

---
Best Regards
Kunihiko Hayashi


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap
  2020-07-31  9:32   ` Kunihiko Hayashi
@ 2020-07-31 19:38     ` John Stultz
  0 siblings, 0 replies; 4+ messages in thread
From: John Stultz @ 2020-07-31 19:38 UTC (permalink / raw)
  To: Kunihiko Hayashi
  Cc: Sumit Semwal, Andrew F . Davis, Benjamin Gaignard, Liam Mark,
	Laura Abbott, Brian Starkey, Christian Koenig, linux-media,
	dri-devel, moderated list:DMA BUFFER SHARING FRAMEWORK, lkml

On Fri, Jul 31, 2020 at 2:32 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> On 2020/07/29 4:17, John Stultz wrote:
> > Do you have a upstream driver that you plan to make use this new call?
>
> Unfortunately I don't have an upstream driver using this call.
>
> This call is called from dma-buf heaps "importer" or "customer",
> and I only made an example (do nothing) importer driver
> to test the call.
>
> > We want to have in-tree users of code added.
>
> I think this is a generic way to use non-default CMA heaps, however,
> we need in-tree "importer" drivers to want to use non-default CMA heaps.
> I don't find it from now.
>

Yea, I and again, I do agree this is functionality that will be
needed. But we'll need to wait for a user (camera driver, etc which
would utilize the reserved cma region) before we can merge it
upstream. :(  Do let me know if you have an out of tree driver that
would make use of it, and we can see what can be done to help upstream
things.

thanks
-john

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-17  1:10 [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap Kunihiko Hayashi
2020-07-28 19:17 ` John Stultz
2020-07-31  9:32   ` Kunihiko Hayashi
2020-07-31 19:38     ` John Stultz

Linux-Media Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-media/0 linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ https://lore.kernel.org/linux-media \
		linux-media@vger.kernel.org
	public-inbox-index linux-media

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-media


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git