On Tue, 2023-09-12 at 10:53 -0500, Rob Herring wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy wrote: > > On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote: > > > On 12/09/2023 08:16, Yong Wu (吴勇) wrote: > > > > Hi Rob, > > > > > > > > Thanks for your review. > > > > > > > > On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote: > > > > > > > > > > External email : Please do not click links or open > attachments until > > > > > you have verified the sender or the content. > > > > > On Mon, Sep 11, 2023 at 10:30:37AM +0800, Yong Wu wrote: > > > > > > This adds the binding for describing a CMA memory for > MediaTek > > > > > SVP(Secure > > > > > > Video Path). > > > > > > > > > > CMA is a Linux thing. How is this related to CMA? > > > > > > > > > > > > > > > > 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 > > > > > > > > > > What makes this specific to Mediatek? Secure video path is > fairly > > > > > common, right? > > > > > > > > Here we just reserve a buffer and would like to create a dma- > buf secure > > > > heap for SVP, then the secure engines(Vcodec and DRM) could > prepare > > > > secure buffer through it. > > > > But the heap driver is pure SW driver, it is not platform > device and > > > > > > All drivers are pure SW. > > > > > > > we don't have a corresponding HW unit for it. Thus I don't > think I > > > > could create a platform dtsi node and use "memory-region" > pointer to > > > > the region. I used RESERVEDMEM_OF_DECLARE currently(The code is > in > > > > [9/9]). Sorry if this is not right. > > > > > > If this is not for any hardware and you already understand this > (since > > > you cannot use other bindings) then you cannot have custom > bindings for > > > it either. > > > > > > > > > > > Then in our usage case, is there some similar method to do > this? or > > > > any other suggestion? > > > > > > Don't stuff software into DTS. > > > > Aren't most reserved-memory bindings just software policy if you > look at it > > that way, though? IIUC this is a pool of memory that is visible and > > available to the Non-Secure OS, but is fundamentally owned by the > Secure > > TEE, and pages that the TEE allocates from it will become > physically > > inaccessible to the OS. Thus the platform does impose constraints > on how the > > Non-Secure OS may use it, and per the rest of the reserved-memory > bindings, > > describing it as a "reusable" reservation seems entirely > appropriate. If > > anything that's *more* platform-related and so DT-relevant than > typical > > arbitrary reservations which just represent "save some memory to > dedicate to > > a particular driver" and don't actually bear any relationship to > firmware or > > hardware at all. > > Yes, a memory range defined by hardware or firmware is within scope > of > DT. (CMA at aribitrary address was questionable.) I guess the memory range is not "defined" by HW in our case, but this reserve buffer is indeed prepared for and used by HW. If this is a normal reserved buffer for some device, we could define a reserved-memory with "shared-dma-pool", then the device use it via "memory-region" property, is this right? Here it is a secure buffer case and this usage relationship is indirect. We create a new heap for this new secure type memory, other users such as VCODEC and DRM allocate secure memory through the new heap. About the aribitrary address is because we have HW register for it. As long as this is a legal dram address, it is fine. When this address is passed into TEE, it will be protected by HW. > > My issue here is more that 'secure video memory' is not any way > Mediatek > specific. Sorry, I don't know if there already is an SVP case in the current kernel. If so, could you help share it? Regarding our special, the new heap driver may be different, and other HWs share this reserve buffer and manage it through this pure SW heap. > AIUI, it's a requirement from certain content providers for > video playback to work. So why the Mediatek specific binding? > > Rob
