From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5FFE3CA0EC3 for ; Tue, 12 Sep 2023 08:28:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BCF2E10E3B9; Tue, 12 Sep 2023 08:28:41 +0000 (UTC) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0F15A10E3B9 for ; Tue, 12 Sep 2023 08:28:40 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-99c1c66876aso679579966b.2 for ; Tue, 12 Sep 2023 01:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1694507318; x=1695112118; darn=lists.freedesktop.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VLzVKDkkOXZ4N+LBDosJ9GVpBHoDNwCkMSqFqUtTQYE=; b=d76qqCeE37ewfCRCavwstP5cbyt79zVLP0i+m+96OVvEfmQ6rAveSmaYybd7/opx40 ePlz/Lw93djNXVTkeVhX34vPyBF5LFeYsNDrX+pK85y+510Pta6jwLlR4COHx5zLlCOm BhRRW3EKOTe800kgJY/JGUwRTeny5sbu9k75+H/gmYZa7nmEp3WA5TKVRUxLIF9LB0nK kcMWiZkas3rnVw1v0rIawsWeKmpY4j/T1Jt8pUDcJJWNnRhJ4Ay05bWk+41T4qMf5WAv oD52n5ZuPs5S0HhgCRW8/rgBekaErg2zHltj1tcaALHMZHVZdoa8/DZAkqYtCznmQXTY J2mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694507318; x=1695112118; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VLzVKDkkOXZ4N+LBDosJ9GVpBHoDNwCkMSqFqUtTQYE=; b=TmwSa02gP9plsglhKAKXA3TFd8PWz79uNPWFU8EptY7a/mRHOMY2BxH+sbPJ1znagr tDMZqv4fHrqShDqCXC1LAn8MyIOxQ7jjxR1vSBAD+64/Tn6B6jmY4OW4e++aTa9K5BrJ BIFY9FHFMwjDQKc5XrYwajGsYOr7SyVY0Bxb5MFisgNfNVM13elDPjPCiRzTT/CTv4rh NClzJ7NUE11Tyos7k8c2Zz0T3KnxH6eNht5uQsyr/AVGoc4iaQ7Kf4SQzOpPGIWNwRdY +7dVZmrGuxpJ1JFpOMLX5E5iHeoubRY7RsWq4Giendn9EpyZTOmS7eJ2Tc8zWycX4EG3 nKbA== X-Gm-Message-State: AOJu0Yzap/hwpZh8LGh0NCO7YCIg4XbaYpi5oNLrhWSdRYxt4eYL+bzI VRbBtxUS+IsY1E9FG7+i0qgIQQ== X-Google-Smtp-Source: AGHT+IHki0HI2dzDOWH07bBWQQqpwLHYoRHu3OffIZhdj/Y17PLOWS/fEeXHSa+TXIl8iuit84dkTA== X-Received: by 2002:a17:907:2ccb:b0:9a9:ee3d:48e3 with SMTP id hg11-20020a1709072ccb00b009a9ee3d48e3mr9692911ejc.12.1694507318462; Tue, 12 Sep 2023 01:28:38 -0700 (PDT) Received: from [192.168.1.20] ([178.197.214.188]) by smtp.gmail.com with ESMTPSA id q18-20020a170906a09200b0099b8234a9fesm6507600ejy.1.2023.09.12.01.28.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Sep 2023 01:28:37 -0700 (PDT) Message-ID: Date: Tue, 12 Sep 2023 10:28:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP Content-Language: en-US To: =?UTF-8?B?WW9uZyBXdSAo5ZC05YuHKQ==?= , "robh@kernel.org" References: <20230911023038.30649-1-yong.wu@mediatek.com> <20230911023038.30649-9-yong.wu@mediatek.com> <20230911154448.GA1279317-robh@kernel.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , "conor+dt@kernel.org" , "benjamin.gaignard@collabora.com" , =?UTF-8?B?S3VvaG9uZyBXYW5nICjnjovlnIvptLsp?= , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "sumit.semwal@linaro.org" , "linaro-mm-sig@lists.linaro.org" , "jstultz@google.com" , "linux-arm-kernel@lists.infradead.org" , "krzysztof.kozlowski+dt@linaro.org" , "matthias.bgg@gmail.com" , "linux-mediatek@lists.infradead.org" , "tjmercier@google.com" , "angelogioacchino.delregno@collabora.com" , "christian.koenig@amd.com" , =?UTF-8?B?SmlhbmppYW8gWmVuZyAo5pu+5YGl5aejKQ==?= , "linux-media@vger.kernel.org" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 >>> --- >>> .../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. Best regards, Krzysztof