On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > On 9/11/2023 8:00 AM, Yong Wu wrote: > > This adds the binding for describing a CMA memory for MediaTek > SVP(Secure > > Video Path). > > > > Signed-off-by: Yong Wu <yong.wu@xxxxxxxxxxxx> > > --- > > .../mediatek,secure_cma_chunkmem.yaml | 42 > +++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/reserved- > memory/mediatek,secure_cma_chunkmem.yaml > > > > diff --git a/Documentation/devicetree/bindings/reserved- > memory/mediatek,secure_cma_chunkmem.yaml > b/Documentation/devicetree/bindings/reserved- > memory/mediatek,secure_cma_chunkmem.yaml > > new file mode 100644 > > index 000000000000..cc10e00d35c4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/reserved- > memory/mediatek,secure_cma_chunkmem.yaml > > @@ -0,0 +1,42 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > http://devicetree.org/schemas/reserved-memory/mediatek,secure_cma_chunkmem.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MediaTek Secure Video Path Reserved Memory > > + > > +description: > > + This binding describes the reserved memory for secure video > path. > > + > > +maintainers: > > + - Yong Wu <yong.wu@xxxxxxxxxxxx> > > + > > +allOf: > > + - $ref: reserved-memory.yaml > > + > > +properties: > > + compatible: > > + const: mediatek,secure_cma_chunkmem > > + > > +required: > > + - compatible > > + - reg > > + - reusable > > + > > +unevaluatedProperties: false > > + > > +examples: > > + - | > > + > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges; > > + > > + reserved-memory@80000000 { > > + compatible = "mediatek,secure_cma_chunkmem"; > > + reusable; > > + reg = <0x80000000 0x18000000>; > > + }; > > + }; > > Instead of having a vendor specific binding for cma area, How about > retrieving > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@xxxxxxxxxxxxx/ > ? > dma_heap_add_cma can just associate cma region and create a heap. So, > we can reuse cma heap > code for allocation instead of replicating that code here. > Thanks for the reference. I guess we can't use it. There are two reasons: a) The secure heap driver is a pure software driver and we have no device for it, therefore we cannot call dma_heap_add_cma. b) The CMA area here is dynamic for SVP. Normally this CMA can be used in the kernel. In the SVP case we use cma_alloc to get it and pass the entire CMA physical start address and size into TEE to protect the CMA region. The original CMA heap cannot help with the TEE part. Thanks. > Thanks, > Vijay > > >
