On Mon, Jan 25, 2021 at 11:07 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Thu, Jan 21, 2021 at 9:55 AM Minchan Kim <minchan@xxxxxxxxxx> wrote: > > .../reserved-memory/dma_heap_chunk.yaml | 56 +++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/reserved-memory/dma_heap_chunk.yaml > > > > diff --git a/Documentation/devicetree/bindings/reserved-memory/dma_heap_chunk.yaml b/Documentation/devicetree/bindings/reserved-memory/dma_heap_chunk.yaml > > new file mode 100644 > > index 000000000000..00db0ae6af61 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/reserved-memory/dma_heap_chunk.yaml > > @@ -0,0 +1,56 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/reserved-memory/dma_heap_chunk.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Device tree binding for chunk heap on DMA HEAP FRAMEWORK > > + > > +description: | > > + The DMA chunk heap is backed by the Contiguous Memory Allocator (CMA) and > > + supports bulk allocation of fixed size pages. > > + > > +maintainers: > > + - Hyesoo Yu <hyesoo.yu@xxxxxxxxxxx> > > + - John Stultz <john.stultz@xxxxxxxxxx> > > + - Minchan Kim <minchan@xxxxxxxxxx> > > + - Hridya Valsaraju<hridya@xxxxxxxxxx> > > + > > + > > +properties: > > + compatible: > > + enum: > > + - dma_heap,chunk > > + > > + chunk-order: > > + description: | > > + order of pages that will get allocated from the chunk DMA heap. > > + maxItems: 1 > > + > > + size: > > + maxItems: 1 > > + > > + alignment: > > + maxItems: 1 > > + > > +required: > > + - compatible > > + - size > > + - alignment > > + - chunk-order > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + reserved-memory { > > + #address-cells = <2>; > > + #size-cells = <1>; > > + > > + chunk_memory: chunk_memory { > > + compatible = "dma_heap,chunk"; > > + size = <0x3000000>; > > Hey Minchan, > Looking closer here, would it make more sense to document the "reg = > <>" parameter here as well instead of just "size = <>"? > > That way the address of the region could be explicitly specified (for > instance, to ensure the CMA region created is 32bit addressable). And > more practically, trying to satisfy the base address alignment checks > in the final patch when its set dynamically may require a fair amount > of luck - I couldn't manage it in my own testing on the hikey960 w/o > resorting to reg= :) > > It does look like the RESERVEDMEM_OF_DECLARE() logic already supports > this, so it's likely just a matter of documenting it here? Thank you John, yes, that makes sense. We will add the 'reg' parameter as well when we send out the next version. Regards, Hridya > > thanks > -john
