Message ID | 20231027-sc7280-remoteprocs-v1-7-05ce95d9315a@fairphone.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp640879vqb; Fri, 27 Oct 2023 07:22:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGS+7K5UAPFikB9CXlXFuIzi3e4jiqFbIv4BOwxpe2532mZwiluRbK9qoIjxxgZOx0z/VvG X-Received: by 2002:a81:e207:0:b0:5b0:4055:73dc with SMTP id p7-20020a81e207000000b005b0405573dcmr607818ywl.14.1698416530512; Fri, 27 Oct 2023 07:22:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698416530; cv=none; d=google.com; s=arc-20160816; b=qhYY5bL3zKHOQ3K10Hd4KZLeR7qFjjBU8eR/8PR8ckDZnv0ECg4zTTGoRfis39/pIq k8PTLPfd9oXi7i0lDkVRYEJNQ330BYOWWyGJP6ogFDqBn79bTA+st9AykxS/H8t4Hc1e 2jFvTK6R69oD72jdkdV1tXv86lPKl8jTxDlpZLuHSPQH0mq99CVznQy9QXchFW+GIOr4 TYv2LqQdJhpwLI7ds9ozy9OfTDW6QC8lSkzrFIo40NubrbKm11E2vutp+9EkM4pSRE0q bBWT8v7rEpnfIlcRRQtZlp5degiDfVASaYRyb4ryAXih5T2ydGzMFjWRYXiEn9i7lgqD wUNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=J39DU+NUP1MyDCVAW5iZmO3nnggaV9wHLOSPXyzWmgg=; fh=4YRGpp4+erIE8EulKv6vTURWMTZkR1ZrVdHONvEW04M=; b=isdgy+ZPzNNQYhegaNXhglVkbfA3z+O50hBr4C3pF2iMTzG9uj8L4jDt9dKLjMh4SH DX85lSxKQhFaUfmZdn+RxfNnwxNEWNYqZ+RKzV2pRqnGZ/nzFdqwiySgAycwZNBoQKX6 N8EfMMBjvUJ/sB4Of7As8Qrv+DXir9Qe5+2j9V0UpkecCXkxyVsr6D2K3OZQI2uk5EuA /Ua2xHu3r6/o0gjCHATb3MAeDS2D2SUzogXwvhdMUO3VGBB9cBxEZthemb/BDb26r2Qe /BU2htmfOOvVSAh1sIaSJfWv1Rt/tRbtfhD+7DY1smN1dlTZATwsnt77Ulod9GxBpGzJ hrWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=TFSMo+ap; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id z2-20020a81a242000000b0059b4ec37224si2565746ywg.541.2023.10.27.07.22.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 07:22:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@fairphone.com header.s=fair header.b=TFSMo+ap; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fairphone.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 185C7835451B; Fri, 27 Oct 2023 07:21:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346193AbjJ0OVJ (ORCPT <rfc822;a1648639935@gmail.com> + 25 others); Fri, 27 Oct 2023 10:21:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346156AbjJ0OUo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Oct 2023 10:20:44 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D729D59 for <linux-kernel@vger.kernel.org>; Fri, 27 Oct 2023 07:20:36 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-9d10f94f70bso17246366b.3 for <linux-kernel@vger.kernel.org>; Fri, 27 Oct 2023 07:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1698416435; x=1699021235; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=J39DU+NUP1MyDCVAW5iZmO3nnggaV9wHLOSPXyzWmgg=; b=TFSMo+aplrEgBdrdWMfEIzyagrImpEPR2+pC27gqzSNHlGCLc7ubmCnNujKvqU94ar ZSWuYq4/i61S+OFqeUyOoLxylr+G0RaCjvISbaKm380BE6wy+pkpz8KZ1IvGhs70quPX 3tv7f8U9WDrkHajo12BMpNKnTGv5w8+aq4tkJXvXN9mK4sv3kDPYXEHcItGdnXoYxcM9 8JcpZig12fn0C4jh100UqrKqKf/gD8V+EAm+c58SjW04/eQb58TyX7oe+tI8nHSf8YCE YNteagO6FPGiOVymnBsvkl6ptl9qFZ6vg4NBRe675D+rId0Ai4E1vPcC6cFj7E1r8grf iEtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698416435; x=1699021235; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J39DU+NUP1MyDCVAW5iZmO3nnggaV9wHLOSPXyzWmgg=; b=C57Kgoeo7VG7xOypJbY7PfWhZ0U1Pja3t50DujUqIl6/LTzdC08B74UydJwGZXgE9g 5uyKSGowQVwZDmK8UXKveDxpDI9BGkIYz2NlVvdfsYV0mPQ0N4j+jd8DZv+VQDk3K5by mRQr/3obcTSNZ77zKYdjGvKuWecw2lgLfi4pho4rgBc7sFDF8bn2zEyIbDoAVyY+OE5o irQmRCmse6SBEPu22xClGNh3vxkvqYh5S1YD89q1d3iaI2X3Qkzl4DdyejFC/f3gx4fS +C5Yo79uOW7IT8IDS1TYwGDNGm3u8YGSsmwfiFqPr9Mx1oh0hFauOziaNFkNrx1JlAhu +7hQ== X-Gm-Message-State: AOJu0YygsfJx0cSbiXazk8EbPmG6ofFugOWtQJPFnDZOywVUP+1ZOvvi rwS1gLt/wP8R6rhm6aoGZkgGoA== X-Received: by 2002:a17:907:7b8e:b0:9ae:69ff:bcdb with SMTP id ne14-20020a1709077b8e00b009ae69ffbcdbmr2575725ejc.31.1698416435247; Fri, 27 Oct 2023 07:20:35 -0700 (PDT) Received: from otso.luca.vpn.lucaweiss.eu (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id z23-20020a170906075700b0099cc36c4681sm1254076ejb.157.2023.10.27.07.20.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 07:20:34 -0700 (PDT) From: Luca Weiss <luca.weiss@fairphone.com> Date: Fri, 27 Oct 2023 16:20:29 +0200 Subject: [PATCH 7/9] arm64: dts: qcom: sc7280: Add CDSP node MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231027-sc7280-remoteprocs-v1-7-05ce95d9315a@fairphone.com> References: <20231027-sc7280-remoteprocs-v1-0-05ce95d9315a@fairphone.com> In-Reply-To: <20231027-sc7280-remoteprocs-v1-0-05ce95d9315a@fairphone.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Manivannan Sadhasivam <mani@kernel.org>, cros-qcom-dts-watchers@chromium.org Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Rob Herring <robh@kernel.org>, =?utf-8?q?Matti_Lehtim=C3=A4ki?= <matti.lehtimaki@gmail.com>, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Weiss <luca.weiss@fairphone.com> X-Mailer: b4 0.12.3 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,URIBL_BLOCKED autolearn=unavailable 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Fri, 27 Oct 2023 07:21:23 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780918812288969303 X-GMAIL-MSGID: 1780918812288969303 |
Series |
Remoteprocs (ADSP, CDSP, WPSS) for SC7280
|
|
Commit Message
Luca Weiss
Oct. 27, 2023, 2:20 p.m. UTC
Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.
The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4
yupik.dtsi since the other areas also seem to match that file there,
though I cannot be sure there.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 +
arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++
2 files changed, 143 insertions(+)
Comments
On 27/10/2023 16:20, Luca Weiss wrote: > Add the node for the ADSP found on the SC7280 SoC, using standard > Qualcomm firmware. > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > yupik.dtsi since the other areas also seem to match that file there, > though I cannot be sure there. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > 2 files changed, 143 insertions(+) Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 10/27/2023 7:50 PM, Luca Weiss wrote: > Add the node for the ADSP found on the SC7280 SoC, using standard > Qualcomm firmware. > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > yupik.dtsi since the other areas also seem to match that file there, > though I cannot be sure there. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > 2 files changed, 143 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > index eb55616e0892..6e5a9d4c1fda 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > no-map; > }; > > + cdsp_mem: memory@88f00000 { > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > + no-map; > + }; > + Just a question, why to do it here, if chrome does not use this ? -Mukesh > camera_mem: memory@8ad00000 { > reg = <0x0 0x8ad00000 0x0 0x500000>; > no-map; > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index cc153f4e6979..e15646289bf7 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { > qcom,bcm-voters = <&apps_bcm_voter>; > }; > > + remoteproc_cdsp: remoteproc@a300000 { > + compatible = "qcom,sc7280-cdsp-pas"; > + reg = <0 0x0a300000 0 0x10000>; > + > + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, > + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; > + interrupt-names = "wdog", "fatal", "ready", "handover", > + "stop-ack", "shutdown-ack"; > + > + clocks = <&rpmhcc RPMH_CXO_CLK>; > + clock-names = "xo"; > + > + power-domains = <&rpmhpd SC7280_CX>, > + <&rpmhpd SC7280_MX>; > + power-domain-names = "cx", "mx"; > + > + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; > + > + memory-region = <&cdsp_mem>; > + > + qcom,qmp = <&aoss_qmp>; > + > + qcom,smem-states = <&cdsp_smp2p_out 0>; > + qcom,smem-state-names = "stop"; > + > + status = "disabled"; > + > + glink-edge { > + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP > + IPCC_MPROC_SIGNAL_GLINK_QMP > + IRQ_TYPE_EDGE_RISING>; > + mboxes = <&ipcc IPCC_CLIENT_CDSP > + IPCC_MPROC_SIGNAL_GLINK_QMP>; > + > + label = "cdsp"; > + qcom,remote-pid = <5>; > + > + fastrpc { > + compatible = "qcom,fastrpc"; > + qcom,glink-channels = "fastrpcglink-apps-dsp"; > + label = "cdsp"; > + qcom,non-secure-domain; > + #address-cells = <1>; > + #size-cells = <0>; > + > + compute-cb@1 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <1>; > + iommus = <&apps_smmu 0x11a1 0x0420>, > + <&apps_smmu 0x1181 0x0420>; > + }; > + > + compute-cb@2 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <2>; > + iommus = <&apps_smmu 0x11a2 0x0420>, > + <&apps_smmu 0x1182 0x0420>; > + }; > + > + compute-cb@3 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <3>; > + iommus = <&apps_smmu 0x11a3 0x0420>, > + <&apps_smmu 0x1183 0x0420>; > + }; > + > + compute-cb@4 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <4>; > + iommus = <&apps_smmu 0x11a4 0x0420>, > + <&apps_smmu 0x1184 0x0420>; > + }; > + > + compute-cb@5 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <5>; > + iommus = <&apps_smmu 0x11a5 0x0420>, > + <&apps_smmu 0x1185 0x0420>; > + }; > + > + compute-cb@6 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <6>; > + iommus = <&apps_smmu 0x11a6 0x0420>, > + <&apps_smmu 0x1186 0x0420>; > + }; > + > + compute-cb@7 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <7>; > + iommus = <&apps_smmu 0x11a7 0x0420>, > + <&apps_smmu 0x1187 0x0420>; > + }; > + > + compute-cb@8 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <8>; > + iommus = <&apps_smmu 0x11a8 0x0420>, > + <&apps_smmu 0x1188 0x0420>; > + }; > + > + /* note: secure cb9 in downstream */ > + > + compute-cb@11 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <11>; > + iommus = <&apps_smmu 0x11ab 0x0420>, > + <&apps_smmu 0x118b 0x0420>; > + }; > + > + compute-cb@12 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <12>; > + iommus = <&apps_smmu 0x11ac 0x0420>, > + <&apps_smmu 0x118c 0x0420>; > + }; > + > + compute-cb@13 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <13>; > + iommus = <&apps_smmu 0x11ad 0x0420>, > + <&apps_smmu 0x118d 0x0420>; > + }; > + > + compute-cb@14 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <14>; > + iommus = <&apps_smmu 0x11ae 0x0420>, > + <&apps_smmu 0x118e 0x0420>; > + }; > + }; > + }; > + }; > + > usb_1: usb@a6f8800 { > compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; > reg = <0 0x0a6f8800 0 0x400>; >
On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > Add the node for the ADSP found on the SC7280 SoC, using standard > > Qualcomm firmware. > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > yupik.dtsi since the other areas also seem to match that file there, > > though I cannot be sure there. > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > --- > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > 2 files changed, 143 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > index eb55616e0892..6e5a9d4c1fda 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > no-map; > > }; > > > > + cdsp_mem: memory@88f00000 { > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > + no-map; > > + }; > > + > > Just a question, why to do it here, if chrome does not use this ? Other memory regions in sc7280.dtsi also get referenced but not actually defined in that file, like mpss_mem and wpss_mem. Alternatively we can also try and solve this differently, but then we should probably also adjust mpss and wpss to be consistent. Apart from either declaring cdsp_mem in sc7280.dtsi or "/delete-property/ memory-region;" for CDSP I don't really have better ideas though. I also imagine these ChromeOS devices will want to enable cdsp at some point but I don't know any plans there. Regards Luca > > -Mukesh > > > camera_mem: memory@8ad00000 { > > reg = <0x0 0x8ad00000 0x0 0x500000>; > > no-map; > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > > index cc153f4e6979..e15646289bf7 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > > @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { > > qcom,bcm-voters = <&apps_bcm_voter>; > > }; > > > > + remoteproc_cdsp: remoteproc@a300000 { > > + compatible = "qcom,sc7280-cdsp-pas"; > > + reg = <0 0x0a300000 0 0x10000>; > > + > > + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, > > + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; > > + interrupt-names = "wdog", "fatal", "ready", "handover", > > + "stop-ack", "shutdown-ack"; > > + > > + clocks = <&rpmhcc RPMH_CXO_CLK>; > > + clock-names = "xo"; > > + > > + power-domains = <&rpmhpd SC7280_CX>, > > + <&rpmhpd SC7280_MX>; > > + power-domain-names = "cx", "mx"; > > + > > + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; > > + > > + memory-region = <&cdsp_mem>; > > + > > + qcom,qmp = <&aoss_qmp>; > > + > > + qcom,smem-states = <&cdsp_smp2p_out 0>; > > + qcom,smem-state-names = "stop"; > > + > > + status = "disabled"; > > + > > + glink-edge { > > + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP > > + IPCC_MPROC_SIGNAL_GLINK_QMP > > + IRQ_TYPE_EDGE_RISING>; > > + mboxes = <&ipcc IPCC_CLIENT_CDSP > > + IPCC_MPROC_SIGNAL_GLINK_QMP>; > > + > > + label = "cdsp"; > > + qcom,remote-pid = <5>; > > + > > + fastrpc { > > + compatible = "qcom,fastrpc"; > > + qcom,glink-channels = "fastrpcglink-apps-dsp"; > > + label = "cdsp"; > > + qcom,non-secure-domain; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + compute-cb@1 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <1>; > > + iommus = <&apps_smmu 0x11a1 0x0420>, > > + <&apps_smmu 0x1181 0x0420>; > > + }; > > + > > + compute-cb@2 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <2>; > > + iommus = <&apps_smmu 0x11a2 0x0420>, > > + <&apps_smmu 0x1182 0x0420>; > > + }; > > + > > + compute-cb@3 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <3>; > > + iommus = <&apps_smmu 0x11a3 0x0420>, > > + <&apps_smmu 0x1183 0x0420>; > > + }; > > + > > + compute-cb@4 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <4>; > > + iommus = <&apps_smmu 0x11a4 0x0420>, > > + <&apps_smmu 0x1184 0x0420>; > > + }; > > + > > + compute-cb@5 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <5>; > > + iommus = <&apps_smmu 0x11a5 0x0420>, > > + <&apps_smmu 0x1185 0x0420>; > > + }; > > + > > + compute-cb@6 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <6>; > > + iommus = <&apps_smmu 0x11a6 0x0420>, > > + <&apps_smmu 0x1186 0x0420>; > > + }; > > + > > + compute-cb@7 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <7>; > > + iommus = <&apps_smmu 0x11a7 0x0420>, > > + <&apps_smmu 0x1187 0x0420>; > > + }; > > + > > + compute-cb@8 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <8>; > > + iommus = <&apps_smmu 0x11a8 0x0420>, > > + <&apps_smmu 0x1188 0x0420>; > > + }; > > + > > + /* note: secure cb9 in downstream */ > > + > > + compute-cb@11 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <11>; > > + iommus = <&apps_smmu 0x11ab 0x0420>, > > + <&apps_smmu 0x118b 0x0420>; > > + }; > > + > > + compute-cb@12 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <12>; > > + iommus = <&apps_smmu 0x11ac 0x0420>, > > + <&apps_smmu 0x118c 0x0420>; > > + }; > > + > > + compute-cb@13 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <13>; > > + iommus = <&apps_smmu 0x11ad 0x0420>, > > + <&apps_smmu 0x118d 0x0420>; > > + }; > > + > > + compute-cb@14 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <14>; > > + iommus = <&apps_smmu 0x11ae 0x0420>, > > + <&apps_smmu 0x118e 0x0420>; > > + }; > > + }; > > + }; > > + }; > > + > > usb_1: usb@a6f8800 { > > compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; > > reg = <0 0x0a6f8800 0 0x400>; > >
Hi, On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > Qualcomm firmware. > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > yupik.dtsi since the other areas also seem to match that file there, > > > though I cannot be sure there. > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > 2 files changed, 143 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > no-map; > > > }; > > > > > > + cdsp_mem: memory@88f00000 { > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > + no-map; > > > + }; > > > + > > > > Just a question, why to do it here, if chrome does not use this ? > > Other memory regions in sc7280.dtsi also get referenced but not actually > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > also try and solve this differently, but then we should probably also > adjust mpss and wpss to be consistent. > > Apart from either declaring cdsp_mem in sc7280.dtsi or > "/delete-property/ memory-region;" for CDSP I don't really have better > ideas though. > > I also imagine these ChromeOS devices will want to enable cdsp at some > point but I don't know any plans there. Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it feels like the dtsi shouldn't be reserving memory. I guess maybe memory regions can't be status "disabled"? -Doug
On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: > Hi, > > On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > > Qualcomm firmware. > > > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > > yupik.dtsi since the other areas also seem to match that file there, > > > > though I cannot be sure there. > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > --- > > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > > 2 files changed, 143 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > > no-map; > > > > }; > > > > > > > > + cdsp_mem: memory@88f00000 { > > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > > + no-map; > > > > + }; > > > > + > > > > > > Just a question, why to do it here, if chrome does not use this ? > > > > Other memory regions in sc7280.dtsi also get referenced but not actually > > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > > also try and solve this differently, but then we should probably also > > adjust mpss and wpss to be consistent. > > > > Apart from either declaring cdsp_mem in sc7280.dtsi or > > "/delete-property/ memory-region;" for CDSP I don't really have better > > ideas though. > > > > I also imagine these ChromeOS devices will want to enable cdsp at some > > point but I don't know any plans there. > > Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it > feels like the dtsi shouldn't be reserving memory. I guess maybe > memory regions can't be status "disabled"? Hi Doug, That's how it works in really any qcom dtsi though. I think in most/all cases normally the reserved-memory is already declared in the SoC dtsi file and also used with the memory-region property. I wouldn't be against adjusting sc7280.dtsi to match the way it's done in the other dtsi files though, so to have all the required labels already defined in the dtsi so it doesn't rely on these labels being defined in the device dts. In other words, currently if you include sc7280.dtsi and try to build, you first have to define the labels mpss_mem and wpss_mem (after this patch series also cdsp_mem and adsp_mem) for it to build. I'm quite neutral either way, let me know :) Regards Luca > > -Doug
Hi, On Mon, Oct 30, 2023 at 7:43 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: > > Hi, > > > > On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > > > Qualcomm firmware. > > > > > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > > > yupik.dtsi since the other areas also seem to match that file there, > > > > > though I cannot be sure there. > > > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > > --- > > > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > > > 2 files changed, 143 insertions(+) > > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > > > no-map; > > > > > }; > > > > > > > > > > + cdsp_mem: memory@88f00000 { > > > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > > > + no-map; > > > > > + }; > > > > > + > > > > > > > > Just a question, why to do it here, if chrome does not use this ? > > > > > > Other memory regions in sc7280.dtsi also get referenced but not actually > > > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > > > also try and solve this differently, but then we should probably also > > > adjust mpss and wpss to be consistent. > > > > > > Apart from either declaring cdsp_mem in sc7280.dtsi or > > > "/delete-property/ memory-region;" for CDSP I don't really have better > > > ideas though. > > > > > > I also imagine these ChromeOS devices will want to enable cdsp at some > > > point but I don't know any plans there. > > > > Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it > > feels like the dtsi shouldn't be reserving memory. I guess maybe > > memory regions can't be status "disabled"? > > Hi Doug, > > That's how it works in really any qcom dtsi though. I think in most/all > cases normally the reserved-memory is already declared in the SoC dtsi > file and also used with the memory-region property. > > I wouldn't be against adjusting sc7280.dtsi to match the way it's done > in the other dtsi files though, so to have all the required labels > already defined in the dtsi so it doesn't rely on these labels being > defined in the device dts. > > In other words, currently if you include sc7280.dtsi and try to build, > you first have to define the labels mpss_mem and wpss_mem (after this > patch series also cdsp_mem and adsp_mem) for it to build. > > I'm quite neutral either way, let me know :) I haven't done a ton of thinking about this, so if I'm spouting gibberish then feel free to ignore me. :-P It just feels weird that when all the "dtsi" files are combined and you look at what you end up on a sc7280 Chrome board that you'll be reserving 32MB of memory for a device that's set (in the same device tree) to be "disabled", right? ...the 32MB is completely wasted, I think. If we wanted to enable the CDSP we'd have to modify the device tree anyway, so it seems like that same modification would set the CDSP to "okay" and also reserve the memory... In that vein, it seems like maybe you could move the "cdsp_mem" to the SoC .dsti file with a status of "disabled". . I guess we don't do that elsewhere, but maybe we should be? As far as I can tell without testing it (just looking at fdt_scan_reserved_mem()) this should work... -Doug
On 10/30/2023 8:33 PM, Doug Anderson wrote: > Hi, > > On Mon, Oct 30, 2023 at 7:43 AM Luca Weiss <luca.weiss@fairphone.com> wrote: >> >> On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: >>> Hi, >>> >>> On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: >>>> >>>> On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: >>>>> >>>>> >>>>> On 10/27/2023 7:50 PM, Luca Weiss wrote: >>>>>> Add the node for the ADSP found on the SC7280 SoC, using standard >>>>>> Qualcomm firmware. >>>>>> >>>>>> The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 >>>>>> yupik.dtsi since the other areas also seem to match that file there, >>>>>> though I cannot be sure there. >>>>>> >>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> >>>>>> --- >>>>>> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + >>>>>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ >>>>>> 2 files changed, 143 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi >>>>>> index eb55616e0892..6e5a9d4c1fda 100644 >>>>>> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi >>>>>> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi >>>>>> @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { >>>>>> no-map; >>>>>> }; >>>>>> >>>>>> + cdsp_mem: memory@88f00000 { >>>>>> + reg = <0x0 0x88f00000 0x0 0x1e00000>; >>>>>> + no-map; >>>>>> + }; >>>>>> + >>>>> >>>>> Just a question, why to do it here, if chrome does not use this ? >>>> >>>> Other memory regions in sc7280.dtsi also get referenced but not actually >>>> defined in that file, like mpss_mem and wpss_mem. Alternatively we can >>>> also try and solve this differently, but then we should probably also >>>> adjust mpss and wpss to be consistent. >>>> >>>> Apart from either declaring cdsp_mem in sc7280.dtsi or >>>> "/delete-property/ memory-region;" for CDSP I don't really have better >>>> ideas though. >>>> >>>> I also imagine these ChromeOS devices will want to enable cdsp at some >>>> point but I don't know any plans there. >>> >>> Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it >>> feels like the dtsi shouldn't be reserving memory. I guess maybe >>> memory regions can't be status "disabled"? >> >> Hi Doug, >> >> That's how it works in really any qcom dtsi though. I think in most/all >> cases normally the reserved-memory is already declared in the SoC dtsi >> file and also used with the memory-region property. >> >> I wouldn't be against adjusting sc7280.dtsi to match the way it's done >> in the other dtsi files though, so to have all the required labels >> already defined in the dtsi so it doesn't rely on these labels being >> defined in the device dts. >> >> In other words, currently if you include sc7280.dtsi and try to build, >> you first have to define the labels mpss_mem and wpss_mem (after this >> patch series also cdsp_mem and adsp_mem) for it to build. >> >> I'm quite neutral either way, let me know :) > > I haven't done a ton of thinking about this, so if I'm spouting > gibberish then feel free to ignore me. :-P It just feels weird that > when all the "dtsi" files are combined and you look at what you end up > on a sc7280 Chrome board that you'll be reserving 32MB of memory for a > device that's set (in the same device tree) to be "disabled", right? > ...the 32MB is completely wasted, I think. If we wanted to enable the > CDSP we'd have to modify the device tree anyway, so it seems like that > same modification would set the CDSP to "okay" and also reserve the > memory... > > In that vein, it seems like maybe you could move the "cdsp_mem" to the > SoC .dsti file with a status of "disabled". . I guess we don't do that > elsewhere, but maybe we should be? As far as I can tell without > testing it (just looking at fdt_scan_reserved_mem()) this should > work... What do you think about moving present reserve memory block from sc7280-chrome-common to sc7280.dtsi and delete the stuff which chrome does not need it sc7280-chrome-common ? -Mukesh > > -Doug
On Tue Oct 31, 2023 at 7:44 AM CET, Mukesh Ojha wrote: > > > On 10/30/2023 8:33 PM, Doug Anderson wrote: > > Hi, > > > > On Mon, Oct 30, 2023 at 7:43 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > >> > >> On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: > >>> Hi, > >>> > >>> On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > >>>> > >>>> On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > >>>>> > >>>>> > >>>>> On 10/27/2023 7:50 PM, Luca Weiss wrote: > >>>>>> Add the node for the ADSP found on the SC7280 SoC, using standard > >>>>>> Qualcomm firmware. > >>>>>> > >>>>>> The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > >>>>>> yupik.dtsi since the other areas also seem to match that file there, > >>>>>> though I cannot be sure there. > >>>>>> > >>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > >>>>>> --- > >>>>>> arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > >>>>>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > >>>>>> 2 files changed, 143 insertions(+) > >>>>>> > >>>>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > >>>>>> index eb55616e0892..6e5a9d4c1fda 100644 > >>>>>> --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > >>>>>> @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > >>>>>> no-map; > >>>>>> }; > >>>>>> > >>>>>> + cdsp_mem: memory@88f00000 { > >>>>>> + reg = <0x0 0x88f00000 0x0 0x1e00000>; > >>>>>> + no-map; > >>>>>> + }; > >>>>>> + > >>>>> > >>>>> Just a question, why to do it here, if chrome does not use this ? > >>>> > >>>> Other memory regions in sc7280.dtsi also get referenced but not actually > >>>> defined in that file, like mpss_mem and wpss_mem. Alternatively we can > >>>> also try and solve this differently, but then we should probably also > >>>> adjust mpss and wpss to be consistent. > >>>> > >>>> Apart from either declaring cdsp_mem in sc7280.dtsi or > >>>> "/delete-property/ memory-region;" for CDSP I don't really have better > >>>> ideas though. > >>>> > >>>> I also imagine these ChromeOS devices will want to enable cdsp at some > >>>> point but I don't know any plans there. > >>> > >>> Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it > >>> feels like the dtsi shouldn't be reserving memory. I guess maybe > >>> memory regions can't be status "disabled"? > >> > >> Hi Doug, > >> > >> That's how it works in really any qcom dtsi though. I think in most/all > >> cases normally the reserved-memory is already declared in the SoC dtsi > >> file and also used with the memory-region property. > >> > >> I wouldn't be against adjusting sc7280.dtsi to match the way it's done > >> in the other dtsi files though, so to have all the required labels > >> already defined in the dtsi so it doesn't rely on these labels being > >> defined in the device dts. > >> > >> In other words, currently if you include sc7280.dtsi and try to build, > >> you first have to define the labels mpss_mem and wpss_mem (after this > >> patch series also cdsp_mem and adsp_mem) for it to build. > >> > >> I'm quite neutral either way, let me know :) > > > > I haven't done a ton of thinking about this, so if I'm spouting > > gibberish then feel free to ignore me. :-P It just feels weird that > > when all the "dtsi" files are combined and you look at what you end up > > on a sc7280 Chrome board that you'll be reserving 32MB of memory for a > > device that's set (in the same device tree) to be "disabled", right? > > ...the 32MB is completely wasted, I think. If we wanted to enable the > > CDSP we'd have to modify the device tree anyway, so it seems like that > > same modification would set the CDSP to "okay" and also reserve the > > memory... > > > > In that vein, it seems like maybe you could move the "cdsp_mem" to the > > SoC .dsti file with a status of "disabled". . I guess we don't do that > > elsewhere, but maybe we should be? As far as I can tell without > > testing it (just looking at fdt_scan_reserved_mem()) this should > > work... > > What do you think about moving present reserve memory block from > sc7280-chrome-common to sc7280.dtsi and delete the stuff which > chrome does not need it sc7280-chrome-common ? Hi Mukesh, I'll do that in v2, thanks! Regards Luca > > -Mukesh > > > > -Doug
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi index eb55616e0892..6e5a9d4c1fda 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { no-map; }; + cdsp_mem: memory@88f00000 { + reg = <0x0 0x88f00000 0x0 0x1e00000>; + no-map; + }; + camera_mem: memory@8ad00000 { reg = <0x0 0x8ad00000 0x0 0x500000>; no-map; diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index cc153f4e6979..e15646289bf7 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { qcom,bcm-voters = <&apps_bcm_voter>; }; + remoteproc_cdsp: remoteproc@a300000 { + compatible = "qcom,sc7280-cdsp-pas"; + reg = <0 0x0a300000 0 0x10000>; + + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MX>; + power-domain-names = "cx", "mx"; + + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; + + memory-region = <&cdsp_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&cdsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + status = "disabled"; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_CDSP + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "cdsp"; + qcom,remote-pid = <5>; + + fastrpc { + compatible = "qcom,fastrpc"; + qcom,glink-channels = "fastrpcglink-apps-dsp"; + label = "cdsp"; + qcom,non-secure-domain; + #address-cells = <1>; + #size-cells = <0>; + + compute-cb@1 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <1>; + iommus = <&apps_smmu 0x11a1 0x0420>, + <&apps_smmu 0x1181 0x0420>; + }; + + compute-cb@2 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <2>; + iommus = <&apps_smmu 0x11a2 0x0420>, + <&apps_smmu 0x1182 0x0420>; + }; + + compute-cb@3 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <3>; + iommus = <&apps_smmu 0x11a3 0x0420>, + <&apps_smmu 0x1183 0x0420>; + }; + + compute-cb@4 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <4>; + iommus = <&apps_smmu 0x11a4 0x0420>, + <&apps_smmu 0x1184 0x0420>; + }; + + compute-cb@5 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <5>; + iommus = <&apps_smmu 0x11a5 0x0420>, + <&apps_smmu 0x1185 0x0420>; + }; + + compute-cb@6 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <6>; + iommus = <&apps_smmu 0x11a6 0x0420>, + <&apps_smmu 0x1186 0x0420>; + }; + + compute-cb@7 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <7>; + iommus = <&apps_smmu 0x11a7 0x0420>, + <&apps_smmu 0x1187 0x0420>; + }; + + compute-cb@8 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <8>; + iommus = <&apps_smmu 0x11a8 0x0420>, + <&apps_smmu 0x1188 0x0420>; + }; + + /* note: secure cb9 in downstream */ + + compute-cb@11 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <11>; + iommus = <&apps_smmu 0x11ab 0x0420>, + <&apps_smmu 0x118b 0x0420>; + }; + + compute-cb@12 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <12>; + iommus = <&apps_smmu 0x11ac 0x0420>, + <&apps_smmu 0x118c 0x0420>; + }; + + compute-cb@13 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <13>; + iommus = <&apps_smmu 0x11ad 0x0420>, + <&apps_smmu 0x118d 0x0420>; + }; + + compute-cb@14 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <14>; + iommus = <&apps_smmu 0x11ae 0x0420>, + <&apps_smmu 0x118e 0x0420>; + }; + }; + }; + }; + usb_1: usb@a6f8800 { compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; reg = <0 0x0a6f8800 0 0x400>;