[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201119011431.GA136599@KEI>
Date: Thu, 19 Nov 2020 10:14:31 +0900
From: Hyesoo Yu <hyesoo.yu@...sung.com>
To: John Stultz <john.stultz@...aro.org>
Cc: Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Matthew Wilcox <willy@...radead.org>, david@...hat.com,
iamjoonsoo.kim@....com, vbabka@...e.cz,
Suren Baghdasaryan <surenb@...gle.com>,
KyongHo Cho <pullip.cho@...sung.com>,
John Dias <joaodias@...gle.com>,
Hridya Valsaraju <hridya@...gle.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Brian Starkey <Brian.Starkey@....com>,
linux-media <linux-media@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, Rob Herring <robh@...nel.org>,
Christian Koenig <christian.koenig@....com>,
"moderated list:DMA BUFFER SHARING FRAMEWORK"
<linaro-mm-sig@...ts.linaro.org>
Subject: Re: [PATCH 4/4] dma-heap: Devicetree binding for chunk heap
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@...nel.org> wrote:
> >
> > From: Hyesoo Yu <hyesoo.yu@...sung.com>
> >
> > Document devicetree binding for chunk heap on dma heap framework
> >
> > Signed-off-by: Hyesoo Yu <hyesoo.yu@...sung.com>
> > Signed-off-by: Minchan Kim <minchan@...nel.org>
> > ---
> > .../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@...aro.org>
> > +
> > +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@socionext.com/
>
> 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.
Powered by blists - more mailing lists