On Tue, Nov 17, 2020 at 07:00:54PM -0800, John Stultz wrote: > On Tue, Nov 17, 2020 at 10:19 AM Minchan Kim <minchan@xxxxxxxxxx> wrote: > > > > From: Hyesoo Yu <hyesoo.yu@xxxxxxxxxxx> > > > > Document devicetree binding for chunk heap on dma heap framework > > > > Signed-off-by: Hyesoo Yu <hyesoo.yu@xxxxxxxxxxx> > > Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx> > > --- > > .../bindings/dma-buf/chunk_heap.yaml | 52 +++++++++++++++++++ > > 1 file changed, 52 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > > > > diff --git a/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml b/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > > new file mode 100644 > > index 000000000000..f382bee02778 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > > @@ -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 <sumit.semwal@xxxxxxxxxx> > > + > > +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"; > > + 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/1594948208-4739-1-git-send-email-hayashi.kunihiko@xxxxxxxxxxxxx/ > > 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 > 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. Please let me know if I misunderstood what you said. Thanks, Regards.
