Message ID | 20230718160833.36397-2-quic_nkela@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp1865932vqt; Tue, 18 Jul 2023 09:29:51 -0700 (PDT) X-Google-Smtp-Source: APBJJlHpLM3Vx175/GqRINliQFM3yPE/5ybtdRVMp+E4tDglrHyZmns7RHEc6/+HejknFUOsxdG7 X-Received: by 2002:a17:906:74c3:b0:993:fba5:cdef with SMTP id z3-20020a17090674c300b00993fba5cdefmr402912ejl.8.1689697790657; Tue, 18 Jul 2023 09:29:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689697790; cv=none; d=google.com; s=arc-20160816; b=caswifmB93ZXvLnQytW24LwcuAfAAdhGaVd9Lgm9rv/elv/9qAi1CJQW6hQwDPTxZ9 Nmn4GukO8RppUoPvra87M9c1GuoLNdYhYUdNJIsiQIXGDq+60LVYvSHBQQa2WydQnieh b9sgV2nYECs1T1rjxOsNg0xQRr3XR8I40CjCLJeZuhLimsbNDVcMCjITCmFC3PaYLgkz W67Q5Ylj0HLkf8OY6MAsL754H91yN04APZzSRdKoZ1dPzSZtr5a2fJydMmgpdcR0YQgu Z0WqQS2/pWtXEVvoByse9brwop8lF8x71osnkLg5lNlCWmslFDLF1ghR6tcMj6jwf2W1 ypIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=2oGvnkersZscNerNLghM9qcUlAK4d1uqGuCo7ejD2vY=; fh=9018RqSWJSEXv424/D/WhujO3KxNtOGtoaADlkHDJ2I=; b=k1Sjf05boaSKYgYPi4xqXiktbP/NXiixhcO9v2bMxLr2cBH2SyzeG1bd+C1qzEPNBz uxlTAYg86/rrGJOABKCMcsyjz5R1QTyx36E18V5bR1rnpWxQV8Z95cXGk2U66kc3jvWZ aRguBh4XH0IKEBFhXzLg18gkp2AJHezZdlFZ1DAeNf+T0UKJuft5Gj+oKza0HH2S/e+J nHQcjMXGWLAyhn3C3o/FhFT2stK7+5+vv8U5jmqBNAVZQCt4t26je7YSADBvEK/ZistD 9Iv8dExBH5RuTejyu+NfLjPsx2Hc0sNyMrLOXZmzy1vUkvH8UXifv4+w4he/KAqQ4jbT r5TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=j+ymbiLb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f21-20020a1709062c5500b0098902d18096si1414947ejh.244.2023.07.18.09.29.27; Tue, 18 Jul 2023 09:29:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=j+ymbiLb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232495AbjGRQJu (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Tue, 18 Jul 2023 12:09:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232347AbjGRQJs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Jul 2023 12:09:48 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C08EEF1; Tue, 18 Jul 2023 09:09:45 -0700 (PDT) Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36IEvqlG011907; Tue, 18 Jul 2023 16:09:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=qcppdkim1; bh=2oGvnkersZscNerNLghM9qcUlAK4d1uqGuCo7ejD2vY=; b=j+ymbiLbNfUG8CX11HFMlf9pND/3UTk4/xhgBOhgOrBqqilIDJyQg8ChmrSTuaEwMCUE AiujO8dm+xGNaI2/Y6Vuz9Xte1THMs4kQkq8QXtC2Mn7lCME7MiAS/6uibfRnxRSEdWu Kd0Sag8BUsYJGKjVRBaNvkI+xhFeEXWzvodg2L53NVlsOWkoht5kCNo64c8uBzyADzyy xzg0QAdWuTJQrLhaCFVpRM/GnoYozu01G4Svf4qtkjEEA834pJcmWCZFy3Kj7LElycen 5xF/Ksc/eXiE2hdqo8DwO3dPu99dQApxZTKdKmfcYStVPN3vgtdykmXJMgZjMbLN5Etr Ug== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3rwqqg926t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 16:09:00 +0000 Received: from nalasex01c.na.qualcomm.com (nalasex01c.na.qualcomm.com [10.47.97.35]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 36IG901N019332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 16:09:00 GMT Received: from car-linux11.qualcomm.com (10.49.16.6) by nalasex01c.na.qualcomm.com (10.47.97.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.30; Tue, 18 Jul 2023 09:08:59 -0700 From: Nikunj Kela <quic_nkela@quicinc.com> To: <sudeep.holla@arm.com> CC: <cristian.marussi@arm.com>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, Nikunj Kela <quic_nkela@quicinc.com> Subject: [PATCH 1/2] dt-bindings: arm: Add qcom specific hvc transport for SCMI Date: Tue, 18 Jul 2023 09:08:32 -0700 Message-ID: <20230718160833.36397-2-quic_nkela@quicinc.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230718160833.36397-1-quic_nkela@quicinc.com> References: <20230718160833.36397-1-quic_nkela@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.49.16.6] X-ClientProxiedBy: nalasex01b.na.qualcomm.com (10.47.209.197) To nalasex01c.na.qualcomm.com (10.47.97.35) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: aYY46OFvVDFhcECyN0Rv5QmCOB7TrfDt X-Proofpoint-ORIG-GUID: aYY46OFvVDFhcECyN0Rv5QmCOB7TrfDt X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-18_12,2023-07-18_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307180149 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771776550557678904 X-GMAIL-MSGID: 1771776550557678904 |
Series |
Add qcom hvc/shmem transport
|
|
Commit Message
Nikunj Kela
July 18, 2023, 4:08 p.m. UTC
Introduce compatible "qcom,scmi-hvc-shmem" for SCMI
transport channel for Qualcomm virtual platforms.
The compatible mandates a shared memory channel.
Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
---
.../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++
1 file changed, 69 insertions(+)
Comments
On Tue, 18 Jul 2023 09:08:32 -0700, Nikunj Kela wrote: > Introduce compatible "qcom,scmi-hvc-shmem" for SCMI > transport channel for Qualcomm virtual platforms. > The compatible mandates a shared memory channel. > > Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> > --- > .../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++ > 1 file changed, 69 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/firmware/arm,scmi.example.dts:194.31-32 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1500: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230718160833.36397-2-quic_nkela@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On 18/07/2023 18:08, Nikunj Kela wrote: > Introduce compatible "qcom,scmi-hvc-shmem" for SCMI > transport channel for Qualcomm virtual platforms. > The compatible mandates a shared memory channel. > > Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> > --- > .../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++ > 1 file changed, 69 insertions(+) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index b138f3d23df8..605b1e997a85 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -45,6 +45,9 @@ properties: > - description: SCMI compliant firmware with OP-TEE transport > items: > - const: linaro,scmi-optee > + - description: SCMI compliant firmware with Qualcomm hvc/shmem transport > + items: > + - const: qcom,scmi-hvc-shmem > > interrupts: > description: > @@ -321,6 +324,16 @@ else: > required: > - linaro,optee-channel-id > > + else: > + if: > + properties: > + compatible: > + contains: > + const: qcom,scmi-hvc-shmem > + then: > + required: > + - shmem Unfortunately this pattern if-else-if-else-if-else does not scale well. Please convert all entries first to allOf:if:then,if:then,if:then (in new patch), and then add new if:then: > + > examples: > - | > firmware { > @@ -444,6 +457,62 @@ examples: > }; > }; > > + - | > + firmware { > + scmi_dpu { No underscores in node names. Node names should be generic. See also an explanation and list of examples (not exhaustive) in DT specification: https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > + compatible = "qcom,scmi-hvc-shmem"; > + shmem = <&shmem_dpu>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + scmi_pd_dpu: protocol@11 { > + reg = <0x11>; > + #power-domain-cells = <1>; > + }; > + }; > + Add only one example, but then only if it differs significantly. I see no differences - except compatible - so maybe no point of examples. > + scmi_gpu { > + compatible = "qcom,scmi-hvc-shmem"; > + shmem = <&shmem_gpu>; This example for sure is not needed - you duplicate above. > + > + interrupts = <GIC_SPI 931 IRQ_TYPE_EDGE_RISING>; > + interrupt-names = "a2p"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + scmi_pd_gpu: protocol@11 { > + reg = <0x11>; > + #power-domain-cells = <1>; > + }; > + }; > + }; > + > + soc { > + #address-cells = <1>; > + #size-cells = <1>; > + > + sram@95c00000 { > + compatible = "mmio-sram"; > + reg = <0x95c00000 0x10000>; > + > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + shmem_dpu: scmi-sram-dpu@95c00000 { > + compatible = "arm,scmi-shmem"; > + reg = <0x95c00000 0x3f0>; > + }; How does these differ from existing example? Best regards, Krzysztof
On 7/18/2023 11:12 AM, Krzysztof Kozlowski wrote: > On 18/07/2023 18:08, Nikunj Kela wrote: >> Introduce compatible "qcom,scmi-hvc-shmem" for SCMI >> transport channel for Qualcomm virtual platforms. >> The compatible mandates a shared memory channel. >> >> Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> >> --- >> .../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++ >> 1 file changed, 69 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> index b138f3d23df8..605b1e997a85 100644 >> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> @@ -45,6 +45,9 @@ properties: >> - description: SCMI compliant firmware with OP-TEE transport >> items: >> - const: linaro,scmi-optee >> + - description: SCMI compliant firmware with Qualcomm hvc/shmem transport >> + items: >> + - const: qcom,scmi-hvc-shmem >> >> interrupts: >> description: >> @@ -321,6 +324,16 @@ else: >> required: >> - linaro,optee-channel-id >> >> + else: >> + if: >> + properties: >> + compatible: >> + contains: >> + const: qcom,scmi-hvc-shmem >> + then: >> + required: >> + - shmem > Unfortunately this pattern if-else-if-else-if-else does not scale well. > Please convert all entries first to allOf:if:then,if:then,if:then (in > new patch), and then add new if:then: Ok! > >> + >> examples: >> - | >> firmware { >> @@ -444,6 +457,62 @@ examples: >> }; >> }; >> >> + - | >> + firmware { >> + scmi_dpu { > No underscores in node names. > > Node names should be generic. See also an explanation and list of > examples (not exhaustive) in DT specification: > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation ACK! > > > >> + compatible = "qcom,scmi-hvc-shmem"; >> + shmem = <&shmem_dpu>; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + scmi_pd_dpu: protocol@11 { >> + reg = <0x11>; >> + #power-domain-cells = <1>; >> + }; >> + }; >> + > Add only one example, but then only if it differs significantly. I see > no differences - except compatible - so maybe no point of examples. Other than the compatible, it also doesn't require smc-id, we read it from shmem region. Will remove examples. > > >> + scmi_gpu { >> + compatible = "qcom,scmi-hvc-shmem"; >> + shmem = <&shmem_gpu>; > This example for sure is not needed - you duplicate above. Right, will remove this example. > >> + >> + interrupts = <GIC_SPI 931 IRQ_TYPE_EDGE_RISING>; >> + interrupt-names = "a2p"; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + scmi_pd_gpu: protocol@11 { >> + reg = <0x11>; >> + #power-domain-cells = <1>; >> + }; >> + }; >> + }; >> + >> + soc { >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + sram@95c00000 { >> + compatible = "mmio-sram"; >> + reg = <0x95c00000 0x10000>; >> + >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges; >> + >> + shmem_dpu: scmi-sram-dpu@95c00000 { >> + compatible = "arm,scmi-shmem"; >> + reg = <0x95c00000 0x3f0>; >> + }; > How does these differ from existing example? It doesn't. Will remove the example as suggested. Thanks > > Best regards, > Krzysztof >
On Tue, Jul 18, 2023 at 09:08:32AM -0700, Nikunj Kela wrote: > Introduce compatible "qcom,scmi-hvc-shmem" for SCMI > transport channel for Qualcomm virtual platforms. > The compatible mandates a shared memory channel. > > Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> > --- > .../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++ > 1 file changed, 69 insertions(+) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index b138f3d23df8..605b1e997a85 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -45,6 +45,9 @@ properties: > - description: SCMI compliant firmware with OP-TEE transport > items: > - const: linaro,scmi-optee > + - description: SCMI compliant firmware with Qualcomm hvc/shmem transport > + items: > + - const: qcom,scmi-hvc-shmem > > interrupts: > description: > @@ -321,6 +324,16 @@ else: > required: > - linaro,optee-channel-id > > + else: > + if: > + properties: > + compatible: > + contains: > + const: qcom,scmi-hvc-shmem > + then: > + required: > + - shmem > + Since this was done after we merged the support recently for extension of SMC/HVC, I need the reason(s) why this can't be used and based on the response this is new change so it can't be because there is a product already supporting this. So for now, NACK until I get the response for these.
On 7/19/2023 3:39 AM, Sudeep Holla wrote: > On Tue, Jul 18, 2023 at 09:08:32AM -0700, Nikunj Kela wrote: >> Introduce compatible "qcom,scmi-hvc-shmem" for SCMI >> transport channel for Qualcomm virtual platforms. >> The compatible mandates a shared memory channel. >> >> Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com> >> --- >> .../bindings/firmware/arm,scmi.yaml | 69 +++++++++++++++++++ >> 1 file changed, 69 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> index b138f3d23df8..605b1e997a85 100644 >> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml >> @@ -45,6 +45,9 @@ properties: >> - description: SCMI compliant firmware with OP-TEE transport >> items: >> - const: linaro,scmi-optee >> + - description: SCMI compliant firmware with Qualcomm hvc/shmem transport >> + items: >> + - const: qcom,scmi-hvc-shmem >> >> interrupts: >> description: >> @@ -321,6 +324,16 @@ else: >> required: >> - linaro,optee-channel-id >> >> + else: >> + if: >> + properties: >> + compatible: >> + contains: >> + const: qcom,scmi-hvc-shmem >> + then: >> + required: >> + - shmem >> + > Since this was done after we merged the support recently for extension of > SMC/HVC, I need the reason(s) why this can't be used and based on the response > this is new change so it can't be because there is a product already > supporting this. So for now, NACK until I get the response for these. Our hypervisor deals with objects and uses object-ids to identify them. The hvc doorbell object is independent of the shmem object created by hypervisor. Hypervisor treats them independently. With the patch you mentioned, hypervisor need to create an association between the doorbell object and shmem object which will make it SCMI specific change in hypervisor. Hypervisor doesn't really care if doorbell is for SCMI or for other purposes hence we are adding this new driver so it can work with our hypervisor ABIs specification.
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index b138f3d23df8..605b1e997a85 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -45,6 +45,9 @@ properties: - description: SCMI compliant firmware with OP-TEE transport items: - const: linaro,scmi-optee + - description: SCMI compliant firmware with Qualcomm hvc/shmem transport + items: + - const: qcom,scmi-hvc-shmem interrupts: description: @@ -321,6 +324,16 @@ else: required: - linaro,optee-channel-id + else: + if: + properties: + compatible: + contains: + const: qcom,scmi-hvc-shmem + then: + required: + - shmem + examples: - | firmware { @@ -444,6 +457,62 @@ examples: }; }; + - | + firmware { + scmi_dpu { + compatible = "qcom,scmi-hvc-shmem"; + shmem = <&shmem_dpu>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_pd_dpu: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + }; + + scmi_gpu { + compatible = "qcom,scmi-hvc-shmem"; + shmem = <&shmem_gpu>; + + interrupts = <GIC_SPI 931 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "a2p"; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_pd_gpu: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + }; + }; + + soc { + #address-cells = <1>; + #size-cells = <1>; + + sram@95c00000 { + compatible = "mmio-sram"; + reg = <0x95c00000 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + shmem_dpu: scmi-sram-dpu@95c00000 { + compatible = "arm,scmi-shmem"; + reg = <0x95c00000 0x3f0>; + }; + + shmem_gpu: scmi-sram-gpu@95c00400 { + compatible = "arm,scmi-shmem"; + reg = <0x95c00400 0x3f0>; + }; + }; + }; + - | firmware { scmi {