Chunk Heap Support on DMA-HEAP

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
gfp_t gfp_mask, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes gfp_t to support __GFP_NORETRY which is propagated into alloc_contig_page to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough pages with __GFP_NORETRY, they could call it without __GFP_NORETRY to increase success ratio this time if they are okay to expense the overhead for the success ratio.

Quoted 26 lines · Minchan Kim

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
gfp_t gfp_mask, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

Quoted 10 lines

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes gfp_t to support __GFP_NORETRY which is propagated into alloc_contig_page to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough pages with __GFP_NORETRY, they could call it without __GFP_NORETRY to increase success ratio this time if they are okay to expense the overhead for the success ratio.

I'm not a friend of connecting __GFP_NORETRY to PCP and LRU draining.

Also, gfp flags apply mostly to compaction (e.g., how to allocate free pages for migration), so this seems a little wrong.

Can we instead introduce

enum alloc_contig_mode {
	/*
	 * Normal mode:
	 *
	 * Retry page migration 5 times, ... TBD
	 *
	 */
	ALLOC_CONTIG_NORMAL = 0,
	/*
	 * Fast mode: e.g., used for bulk allocations.
         *
	 * Don't retry page migration if it fails, don't drain PCP
         * lists, don't drain LRU.
	 */
	ALLOC_CONTIG_FAST,
};

From: Hyesoo Yu <[email protected]>

The heaps could be added as module, so some functions should be exported to register dma-heaps. And dma-heap of module can use cma area to allocate and free. However the function related cma is not exported now. Let's export them for next patches.

Signed-off-by Hyesoo Yu <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

---
 drivers/dma-buf/dma-heap.c | 2 ++
 mm/cma.c                   | 3 +++
 2 files changed, 5 insertions(+)

drivers/dma-buf/dma-heap.c +1 -0

index afd22c9dbdcf..cc6339cbca09 100644
@@ -189,6 +189,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
 {
        return heap->priv;
 }
+EXPORT_SYMBOL_GPL(dma_heap_get_drvdata);
 
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 {

mm/cma.c +2 -0

index 7c11ec2dc04c..87834e2966fa 100644
@@ -54,6 +54,7 @@ const char *cma_get_name(const struct cma *cma)
 {
        return cma->name;
 }
+EXPORT_SYMBOL_GPL(cma_get_name);
 
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
                                             unsigned int align_order)

@@ -498,6 +499,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
        pr_debug("%s(): returned %p\n", __func__, page);
        return page;
 }
+EXPORT_SYMBOL_GPL(cma_alloc);
 
 /*
  * cma_alloc_bulk() - allocate high order bulk pages from contiguous area with

On Tue, 17 Nov 2020 10:19:34 -0800 Minchan Kim wrote:

drivers/dma-buf/heaps/chunk_heap.c new file +17 -0

+
+static int chunk_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+	struct chunk_heap_buffer *buffer = dmabuf->priv;
+	struct sg_table *table = &buffer->sg_table;
+	unsigned long addr = vma->vm_start;
+	struct sg_page_iter piter;
+	int ret;
+
+	for_each_sgtable_page(table, &piter, vma->vm_pgoff) {
+		struct page *page = sg_page_iter_page(&piter);
+
+		ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE,
+				      vma->vm_page_prot);
+		if (ret)
+			return ret;
+		addr = PAGE_SIZE;

Typo?

		addr += PAGE_SIZE;

drivers/dma-buf/heaps/chunk_heap.c new file +5 -0

+		if (addr >= vma->vm_end)
+			return 0;
+	}
+	return 0;
+}

From: Hyesoo Yu <[email protected]>

Document devicetree binding for chunk heap on dma heap framework

Signed-off-by Hyesoo Yu <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

---
 .../bindings/dma-buf/chunk_heap.yaml          | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml

Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml new file +42 -0

new file mode 100644
index 000000000000..f382bee02778
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma-buf/chunk_heap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Device tree binding for chunk heap on DMA HEAP FRAMEWORK
+
+maintainers:
+  - Sumit Semwal <[email protected]>
+
+description: |
+  The chunk heap is backed by the Contiguous Memory Allocator (CMA) and
+  allocates the buffers that are made up to a list of fixed size chunks
+  taken from CMA. Chunk sizes are configurated when the heaps are created.
+
+properties:
+  compatible:
+    enum:
+      - dma_heap,chunk
+
+  memory-region:
+    maxItems: 1
+
+  alignment:
+    maxItems: 1
+
+required:
+  - compatible
+  - memory-region
+  - alignment
+
+additionalProperties: false
+
+examples:
+  - |
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <1>;
+
+        chunk_memory: chunk_memory {
+            compatible = "shared-dma-pool";

Quoted 60 lines · Minchan Kim

From: Hyesoo Yu <[email protected]>

Document devicetree binding for chunk heap on dma heap framework

Signed-off-by Hyesoo Yu <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

---
 .../bindings/dma-buf/chunk_heap.yaml          | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml

Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml new file +42 -0

new file mode 100644
index 000000000000..f382bee02778
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: https://protect2.fireeye.com/v1/url?k=9020a1f6-cfbb98fd-90212ab9-002590f5b904-5057bc6b174b6a8e&q=1&e=76ff8b54-517c-4389-81b9-fa1446ad08bf&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdma-buf%2Fchunk_heap.yaml%23
+$schema: https://protect2.fireeye.com/v1/url?k=876fa02f-d8f49924-876e2b60-002590f5b904-e220c9cf0d714704&q=1&e=76ff8b54-517c-4389-81b9-fa1446ad08bf&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
+
+title: Device tree binding for chunk heap on DMA HEAP FRAMEWORK
+
+maintainers:
+  - Sumit Semwal <[email protected]>
+
+description: |
+  The chunk heap is backed by the Contiguous Memory Allocator (CMA) and
+  allocates the buffers that are made up to a list of fixed size chunks
+  taken from CMA. Chunk sizes are configurated when the heaps are created.
+
+properties:
+  compatible:
+    enum:
+      - dma_heap,chunk
+
+  memory-region:
+    maxItems: 1
+
+  alignment:
+    maxItems: 1
+
+required:
+  - compatible
+  - memory-region
+  - alignment
+
+additionalProperties: false
+
+examples:
+  - |
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <1>;
+
+        chunk_memory: chunk_memory {
+            compatible = "shared-dma-pool";

Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml line 52

Quoted 10 lines

Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml new file +10 -0

+            reusable;
+            size = <0x10000000>;
+        };
+    };
+
+    chunk_default_heap: chunk_default_heap {
+        compatible = "dma_heap,chunk";
+        memory-region = <&chunk_memory>;
+        alignment = <0x10000>;
+    };

So I suspect Rob will push back on this as he has for other dt bindings related to ion/dmabuf heaps (I tried to push a similar solution to exporting multiple CMA areas via dmabuf heaps).

The proposal he seemed to like best was having an in-kernel function
that a driver would call to initialize the heap (associated with the
CMA region the driver is interested in). Similar to Kunihiko Hayashi's
patch here:
- https://lore.kernel.org/lkml/[email protected]/

The one sticking point for that patch (which I think is a good one), is that we don't have any in-tree users, so it couldn't be merged yet.

A similar approach might be good here, but again we probably need to have at least one in-tree user which could call such a registration function.

thanks
-john

Quoted 13 lines · John Stultz

So I suspect Rob will push back on this as he has for other dt bindings related to ion/dmabuf heaps (I tried to push a similar solution to exporting multiple CMA areas via dmabuf heaps).

The proposal he seemed to like best was having an in-kernel function
that a driver would call to initialize the heap (associated with the
CMA region the driver is interested in). Similar to Kunihiko Hayashi's
patch here:
- https://lore.kernel.org/lkml/[email protected]/

The one sticking point for that patch (which I think is a good one), is that we don't have any in-tree users, so it couldn't be merged yet.

Quoted 3 lines

A similar approach might be good here, but again we probably need to have at least one in-tree user which could call such a registration function.

Thanks for your review.

The chunk heap is not considered for device-specific reserved memory and specific driver.
It is similar to system heap, but it only collects high-order pages by using specific cma-area for performance.

It is strange that there is in-tree user who registers chunk heap. (Wouldn't it be strange for some users to register the system heap?)

Is there a reason to use dma-heap framework to add cma-area for specific device ?

Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. For exclusive access, I guess, the device don't need to register dma-heap for cma area.

Quoted 15 lines · Hyesoo Yu

Quoted 13 lines · John Stultz

So I suspect Rob will push back on this as he has for other dt bindings related to ion/dmabuf heaps (I tried to push a similar solution to exporting multiple CMA areas via dmabuf heaps).

The proposal he seemed to like best was having an in-kernel function
that a driver would call to initialize the heap (associated with the
CMA region the driver is interested in). Similar to Kunihiko Hayashi's
patch here:
- https://lore.kernel.org/lkml/[email protected]/

The one sticking point for that patch (which I think is a good one), is that we don't have any in-tree users, so it couldn't be merged yet.

Quoted 8 lines

Quoted 3 lines

A similar approach might be good here, but again we probably need to have at least one in-tree user which could call such a registration function.

Thanks for your review.

The chunk heap is not considered for device-specific reserved memory and specific driver.
It is similar to system heap, but it only collects high-order pages by using specific cma-area for performance.

So, yes I agree, the chunk heap isn't device specific. It's just that the CMA regions usually are tied to devices.

The main objection to this style of solution has been due to the fact that the DTS is supposed to describe the physical hardware (in an OS agnostic way), rather than define configuration info for Linux software drivers.

Obviously this can be quibbled about, as the normal way of tying devices to CMA has some assumptions of what the driver will use that region for, rather than somehow representing a physical tie between a memory reservation and a device. Nonetheless, Rob has been hesitant to take any sort of ION/DmaBuf Heap DT devices, and has been more interested in some device having the memory reservation reference and the driver for that doing the registration.

Quoted 2 lines

It is strange that there is in-tree user who registers chunk heap. (Wouldn't it be strange for some users to register the system heap?)

Well, as there's no reservation/configuration needed, the system heap can register itself.

The CMA heap currently only registers the default CMA heap, as we didn't want to expose all CMA regions and there's otherwise no way to pick and choose.

Quoted 5 lines

Is there a reason to use dma-heap framework to add cma-area for specific device ?

Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. For exclusive access, I guess, the device don't need to register dma-heap for cma area.

It's not really about exclusive access. More just that if you want to bind a memory reservation/region (cma or otherwise), at least for DTS, it needs to bind with some device in DT.

Then the device driver can register that region with a heap driver. This avoids adding new Linux-specific software bindings to DT. It becomes a driver implementation detail instead. The primary user of the heap type would probably be a practical pick (ie the display or isp driver).

The other potential solution Rob has suggested is that we create some tag for the memory reservation (ie: like we do with cma: "reusable"), which can be used to register the region to a heap. But this has the problem that each tag has to be well defined and map to a known heap.

thanks
-john

Quoted 15 lines · Hyesoo Yu

Quoted 13 lines · John Stultz

So I suspect Rob will push back on this as he has for other dt bindings related to ion/dmabuf heaps (I tried to push a similar solution to exporting multiple CMA areas via dmabuf heaps).

The proposal he seemed to like best was having an in-kernel function
that a driver would call to initialize the heap (associated with the
CMA region the driver is interested in). Similar to Kunihiko Hayashi's
patch here:
- https://lore.kernel.org/lkml/[email protected]/

The one sticking point for that patch (which I think is a good one), is that we don't have any in-tree users, so it couldn't be merged yet.

Quoted 8 lines

Quoted 3 lines

A similar approach might be good here, but again we probably need to have at least one in-tree user which could call such a registration function.

Thanks for your review.

The chunk heap is not considered for device-specific reserved memory and specific driver.
It is similar to system heap, but it only collects high-order pages by using specific cma-area for performance.

So, yes I agree, the chunk heap isn't device specific. It's just that the CMA regions usually are tied to devices.

The main objection to this style of solution has been due to the fact that the DTS is supposed to describe the physical hardware (in an OS agnostic way), rather than define configuration info for Linux software drivers.

Obviously this can be quibbled about, as the normal way of tying devices to CMA has some assumptions of what the driver will use that region for, rather than somehow representing a physical tie between a memory reservation and a device. Nonetheless, Rob has been hesitant to take any sort of ION/DmaBuf Heap DT devices, and has been more interested in some device having the memory reservation reference and the driver for that doing the registration.

Quoted 2 lines

It is strange that there is in-tree user who registers chunk heap. (Wouldn't it be strange for some users to register the system heap?)

Well, as there's no reservation/configuration needed, the system heap can register itself.

The CMA heap currently only registers the default CMA heap, as we didn't want to expose all CMA regions and there's otherwise no way to pick and choose.

Quoted 6 lines

Is there a reason to use dma-heap framework to add cma-area for specific device ?

Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. For exclusive access, I guess, the device don't need to register dma-heap for cma area.

It's not really about exclusive access. More just that if you want to bind a memory reservation/region (cma or otherwise), at least for DTS, it needs to bind with some device in DT.

Then the device driver can register that region with a heap driver. This avoids adding new Linux-specific software bindings to DT. It becomes a driver implementation detail instead. The primary user of the heap type would probably be a practical pick (ie the display or isp driver).

The other potential solution Rob has suggested is that we create some tag for the memory reservation (ie: like we do with cma: "reusable"), which can be used to register the region to a heap. But this has the problem that each tag has to be well defined and map to a known heap.

Quoted 3 lines · John Stultz

The CMA heap currently only registers the default CMA heap, as we didn't want to expose all CMA regions and there's otherwise no way to pick and choose.

Yub.

dma-buf really need a way to make exclusive CMA area. Otherwise, default CMA would be shared among drivers and introduce fragmentation easily since we couldn't control other drivers. In such aspect, I don't think current cma-heap works if userspace needs big memory chunk.

Here, the problem is there is no in-kernel user to bind the specific CMA area because the owner will be random in userspace via dma-buf interface.

Quoted 10 lines

Quoted 5 lines

Is there a reason to use dma-heap framework to add cma-area for specific device ?

Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. For exclusive access, I guess, the device don't need to register dma-heap for cma area.

It's not really about exclusive access. More just that if you want to bind a memory reservation/region (cma or otherwise), at least for DTS, it needs to bind with some device in DT.

Quoted 5 lines

Then the device driver can register that region with a heap driver. This avoids adding new Linux-specific software bindings to DT. It becomes a driver implementation detail instead. The primary user of the heap type would probably be a practical pick (ie the display or isp driver).

If it's the only solution, we could create some dummy driver which has only module_init and bind it from there but I don't think it's a good idea.

Quoted 4 lines

The other potential solution Rob has suggested is that we create some tag for the memory reservation (ie: like we do with cma: "reusable"), which can be used to register the region to a heap. But this has the problem that each tag has to be well defined and map to a known heap.

Do you think that's the only solution to make progress for this feature? Then, could you elaborate it a bit more or any other ideas from dma-buf folks?

Quoted 11 lines · Minchan Kim

Quoted 3 lines · John Stultz

The CMA heap currently only registers the default CMA heap, as we didn't want to expose all CMA regions and there's otherwise no way to pick and choose.

Yub.

dma-buf really need a way to make exclusive CMA area. Otherwise, default CMA would be shared among drivers and introduce fragmentation easily since we couldn't control other drivers. In such aspect, I don't think current cma-heap works if userspace needs big memory chunk.

Yes, the default CMA region is not always optimal.

That's why I was hopeful for Kunihiko Hayashi's patch to allow for exposing specific cma regions:
https://lore.kernel.org/lkml/[email protected]/

I think it would be a good solution, but all we need is *some* driver which can be considered the primary user/owner of the cma region which would then explicitly export it via the dmabuf heaps.

Quoted 3 lines

Here, the problem is there is no in-kernel user to bind the specific CMA area because the owner will be random in userspace via dma-buf interface.

Well, while I agree that conceptually the dmabuf heaps allow for allocations for multi-device pipelines, and thus are not tied to specific devices. I do think that the memory types exposed are likely to have specific devices/drivers in the pipeline that it matters most to. So I don't see a big issue with the in-kernel driver registering a specific CMA region as a dmabuf heap.

Quoted 17 lines

Quoted 11 lines

Quoted 6 lines

Is there a reason to use dma-heap framework to add cma-area for specific device ?

Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. For exclusive access, I guess, the device don't need to register dma-heap for cma area.

It's not really about exclusive access. More just that if you want to bind a memory reservation/region (cma or otherwise), at least for DTS, it needs to bind with some device in DT.

Quoted 5 lines

Then the device driver can register that region with a heap driver. This avoids adding new Linux-specific software bindings to DT. It becomes a driver implementation detail instead. The primary user of the heap type would probably be a practical pick (ie the display or isp driver).

Quoted 3 lines

If it's the only solution, we could create some dummy driver which has only module_init and bind it from there but I don't think it's a good idea.

Yea, an un-upstreamable dummy driver is maybe what it devolves to in the worst case. But I suspect it would be cleaner for a display or ISP driver that benefits most from the heap type to add the reserved memory reference to their DT node, and on init for them to register the region with the dmabuf heap code.

Quoted 10 lines

Quoted 6 lines

The other potential solution Rob has suggested is that we create some tag for the memory reservation (ie: like we do with cma: "reusable"), which can be used to register the region to a heap. But this has the problem that each tag has to be well defined and map to a known heap.

Do you think that's the only solution to make progress for this feature? Then, could you elaborate it a bit more or any other ideas from dma-buf folks?

I'm skeptical of that DT tag approach working out, as we'd need a new DT binding for the new tag name, and we'd have to do so for each new heap type that needs this (so non-default cma, your chunk heap, whatever other similar heap types that use reserved regions folks come up with). Having *some* driver take ownership for the reserved region and register it with the appropriate heap type seems much cleaner/flexible and avoids mucking with the DT ABI.

thanks
-john

Quoted 6 lines · John Stultz

Well, while I agree that conceptually the dmabuf heaps allow for allocations for multi-device pipelines, and thus are not tied to specific devices. I do think that the memory types exposed are likely to have specific devices/drivers in the pipeline that it matters most to. So I don't see a big issue with the in-kernel driver registering a specific CMA region as a dmabuf heap.

Then, I am worry about that we spread out dma_heap_add_cma to too many drivers since kernel doesn't how userspace will use it.
For example, system 1 could have device A-B-C pipeline so they added it A driver. After that, system 2 could have device B-C-D pipeline so they add dma_heap_add_cma into B device.

Quoted 5 lines

Yea, an un-upstreamable dummy driver is maybe what it devolves to in the worst case. But I suspect it would be cleaner for a display or ISP driver that benefits most from the heap type to add the reserved memory reference to their DT node, and on init for them to register the region with the dmabuf heap code.

As I mentioned above, it could be a display at this moment but it could be different driver next time. If I miss your point, let me know.

Quoted 8 lines · Minchan Kim

Quoted 6 lines · John Stultz

Well, while I agree that conceptually the dmabuf heaps allow for allocations for multi-device pipelines, and thus are not tied to specific devices. I do think that the memory types exposed are likely to have specific devices/drivers in the pipeline that it matters most to. So I don't see a big issue with the in-kernel driver registering a specific CMA region as a dmabuf heap.

Quoted 5 lines

Then, I am worry about that we spread out dma_heap_add_cma to too many drivers since kernel doesn't how userspace will use it.
For example, system 1 could have device A-B-C pipeline so they added it A driver. After that, system 2 could have device B-C-D pipeline so they add dma_heap_add_cma into B device.

I'm not sure I see this as a major issue? If the drivers add it based on the dt memory reference, those will be configured to not add duplicate heaps (and even so the heap driver can also ensure we don't try to add a heap twice).

Quoted 10 lines

Quoted 6 lines

Yea, an un-upstreamable dummy driver is maybe what it devolves to in the worst case. But I suspect it would be cleaner for a display or ISP driver that benefits most from the heap type to add the reserved memory reference to their DT node, and on init for them to register the region with the dmabuf heap code.

As I mentioned above, it could be a display at this moment but it could be different driver next time. If I miss your point, let me know.

I guess I just don't see potentially having the registration calls added to multiple drivers as a big problem.

Ideally, yes, I'd probably rather see a DT node that would allow the heap driver to register specified regions, but that's been NACKed multiple times. Given that, having hooks in device drivers to export the region seems to me like the next best approach, as it avoids DT ABI ( if ends up its a bad approach, its not something we have to keep).

The bigger problem right now is not that there are too many places the registration call would be made from, but that there aren't upstream drivers which I'm aware of where it would currently make sense to add specific dma_heap_add_cma() registration hooks to. We need an upstream user of Kunihiko Hayashi's patch.

This patchset introduces a new dma heap, chunk heap that makes it easy to perform the bulk allocation of high order pages. It has been created to help optimize the 4K/8K HDR video playback with secure DRM HW to protect contents on memory. The HW needs physically contiguous memory chunks up to several hundred MB memory.

The chunk heap is registered by device tree with alignment and memory node of Contiguous Memory Allocator(CMA). Alignment defines chunk page size. For example, alignment 0x1_0000 means chunk page size is 64KB. The phandle to memory node indicates contiguous memory allocator(CMA). If device node doesn't have cma, the registration of chunk heap fails.

This patchset is against on next-20201110.

The patchset includes the following:
 - cma_alloc_bulk API
 - export dma-heap API to register kernel module dma heap.
 - add chunk heap implementation.
 - devicetree

Hyesoo Yu (3):
  dma-buf: add export symbol for dma-heap
  dma-buf: heaps: add chunk heap to dmabuf heaps
  dma-heap: Devicetree binding for chunk heap

Minchan Kim (1):
  mm: introduce cma_alloc_bulk API

 .../bindings/dma-buf/chunk_heap.yaml          |  52 ++ drivers/dma-buf/dma-heap.c                    |   2 + drivers/dma-buf/heaps/Kconfig                 |   9 + drivers/dma-buf/heaps/Makefile                |   1 + drivers/dma-buf/heaps/chunk_heap.c            | 458 ++++++++++++++++++ include/linux/cma.h                           |   5 + include/linux/page-isolation.h                |   1 + mm/cma.c                                      | 129 ++++- mm/page_alloc.c                               |  19 +- mm/page_isolation.c                           |   3 +-

 10 files changed, 666 insertions(+), 13 deletions(-)

 create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml create mode 100644 drivers/dma-buf/heaps/chunk_heap.c