On 2020/08/01 4:38, John Stultz wrote:
On Fri, Jul 31, 2020 at 2:32 AM Kunihiko Hayashi
<hayashi.kunihiko@xxxxxxxxxxxxx> 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.
Sorry for late.
Before I prepare or find a user driver as "importer",
I think something is different in this patch.
This patch makes it possible to treat non-default CMA connected to
"importer" device with memory-region as dma-buf heaps.
However, the allocated memory from this dma-buf heaps can be used
for "any" devices, and the "importer" can treat memories from other
dma-buf heaps.
So, the "importer" and the non-default CMA aren't directly related,
and I think an "exporter" for the non-default CMA should be enabled.
In paticular, the kernel initializer (as an "exporter") calls
dma_heap_add_cma() for all CMAs defined in Devicetree, and
the device files associated with each CMA appear under "/dev/dma_heap/".
For example:
/dev/dma_heap/linux,cma@10000000
/dev/dma_heap/linux,cma@11000000
/dev/dma_heap/linux,cma@12000000
...
All of these device files can be fairly allocated to any "importer" device.
Actually I think that the kernel should executes dma_heap_add_cma()
for ALL defined reserved-memory nodes.
If this idea hasn't been discussed yet and this is reasonable,
I'll prepare RFC patches.
Thank you,
---
Best Regards
Kunihiko Hayashi
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
