Message ID | 20221114-narmstrong-sm8550-upstream-mpss_dsm-v1-1-158dc2bb6e96@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp60488wru; Wed, 16 Nov 2022 02:18:24 -0800 (PST) X-Google-Smtp-Source: AA0mqf4q5OKb+NA1wBNNEnBS3GotsTu+oZJBssr2QMIdMs8+49w/U5at8elNJK+iuTbQ/skrm732 X-Received: by 2002:a17:906:d8a3:b0:7a0:9d58:5c7b with SMTP id qc3-20020a170906d8a300b007a09d585c7bmr17361394ejb.115.1668593904658; Wed, 16 Nov 2022 02:18:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668593904; cv=none; d=google.com; s=arc-20160816; b=bOSlZzeMSrQJlW4SGnJEvgSjsSW7irT2E0SBYgAxDPAQ0ITaQMTmeOoXAhzuQJaqW0 ZuStHc5PHU5M7wb6ZNrRWTRLuJYUjmjcywWLG/hFs8idJNEa4/nBRSovrpc+EJqOjtHb VGC+KK3a8Eejl5xV6JuWDB6XLLGa0aHvB0wtNbQSDZsW5IWB2CeccnDagUzWlqSyxa+C IcJ5z7YqmpmWHrVrSrS0kgbq4vc5eZJMFonDTEtXcWeVwLcc70gvyrpbt/gkBqi28Qv7 d2YSwNlo2SFWfm3xbvvuUU/Iy0JSGnIY7xbQ7HexepL5lM2Sybpgbi2iM3Yf0QiW71MP anbg== 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=Pu7n9N+0O5BDIzgboei0EVzrkBbQ6PttgZW+WxRWsp0=; b=yPUY6/Md1Hx9dzvrJVYoDFNB/7Gu870SGvQNvOgSHzo9OTd9wDQ0duO2L16La1Q0fz U/QdAYPKa1i5D0i/gxqheX7QaNc7Mjn+74/CMyAsqBrUm1y+RV88FbrSmEULkCLj3z8h Ih2Zw+vbHK7F5yKcoiww8/25v3rlzjfwFP2SGi34hSA8GJaWVfMb/bdVkHM/ly/Bhldu TyuWU/PZzHKEjehJJyeDIShYMQEwBd1LoshmlMKKbhZFPpyfplpY4QpG7WrTi+zGRNir NjVIIF7mInp1zSxiKILlpxSv8/LpMi6SRqTT1Xh7oWlEt3cOzdfAHa7+70IFXE9iJfdM Z8iA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="G7Z5/x6S"; 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=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh18-20020a1709076e9200b0078e11e9286csi11359131ejc.195.2022.11.16.02.17.59; Wed, 16 Nov 2022 02:18:24 -0800 (PST) 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=@linaro.org header.s=google header.b="G7Z5/x6S"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232965AbiKPKRR (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 05:17:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232877AbiKPKQ7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 05:16:59 -0500 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2D9FBF47 for <linux-kernel@vger.kernel.org>; Wed, 16 Nov 2022 02:16:57 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id cl5so29093062wrb.9 for <linux-kernel@vger.kernel.org>; Wed, 16 Nov 2022 02:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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=Pu7n9N+0O5BDIzgboei0EVzrkBbQ6PttgZW+WxRWsp0=; b=G7Z5/x6S57rt6bfL4e5y1ndNXKgn6SQ2r47XxAXklpogTiYtUVc4LvU9HBUhUJIqGW CK/RD7IJL+hmfAug62nieUT/iNNNbFxjBjG54g3DznfPOnDpToG1tWBl4fE/I4oVSyCO 4jEnCBQaDRAweOJsgDP1ODET/dfz5n8L5XZklazjKgl8+BIae0F87+KL+D9X0+XZwIT4 QsUF30r9TEYrHr1ijeJgDRUSdBdISVqwZplQOwRi2+nivnzQ3td5bKYB3Geca08WoPET egj5FJHXUum+8qtFXc8ivx36sR65ZqtkN7iFMkqqdE/T2j7mbOW9ia4E7/WwmzHAHsN6 SVfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Pu7n9N+0O5BDIzgboei0EVzrkBbQ6PttgZW+WxRWsp0=; b=m32N/nZ7tHx2QvIt9pVkgq24V6myb5HMf09SXsVWBqHO75L9E7FDscgWLFnYS5D0nI rZsP5xyIi+yRvFRSLc0EBnard5qKSfudhYqpLY1hhDqqLqv+sIIPBJ6chvfQULaXW4Ym wTuTf4HywbmJfAp2x3Sr4bLcjOsm+0ZGty3RytvjpMg+l43frYH83MUipEV6T2Ps+HSK W4S7iba7JHGc53Cvk85hzdDvtYPe7kGpeHYekpboX3GJNGT3Y4yxFABUViW0P5Yovc0P kS75k4wuHRcTgEueOkBSZWklnklJ5iqJXm6m8vLYUu+bAgPk7C8vu0Ks78lWmRK2kcZ2 0EHw== X-Gm-Message-State: ANoB5pmaMYuO89NFz3kXQ3ADbAgh9JSb+myYxnBgSYpZ5Xcl6DsjGk7A TVvxlHtdCiZb2+pxm44SmlDxJg== X-Received: by 2002:a5d:43d0:0:b0:236:4e3c:7720 with SMTP id v16-20020a5d43d0000000b002364e3c7720mr13509880wrr.674.1668593816360; Wed, 16 Nov 2022 02:16:56 -0800 (PST) Received: from arrakeen.starnux.net ([2a01:e0a:982:cbb0:52eb:f6ff:feb3:451a]) by smtp.gmail.com with ESMTPSA id c4-20020a5d4f04000000b0023672104c24sm15081007wru.74.2022.11.16.02.16.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 02:16:56 -0800 (PST) From: Neil Armstrong <neil.armstrong@linaro.org> Date: Wed, 16 Nov 2022 11:16:52 +0100 Subject: [PATCH 1/2] dt-bindings: reserved-memory: document Qualcomm MPSS DSM memory MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20221114-narmstrong-sm8550-upstream-mpss_dsm-v1-1-158dc2bb6e96@linaro.org> References: <20221114-narmstrong-sm8550-upstream-mpss_dsm-v1-0-158dc2bb6e96@linaro.org> In-Reply-To: <20221114-narmstrong-sm8550-upstream-mpss_dsm-v1-0-158dc2bb6e96@linaro.org> To: Konrad Dybcio <konrad.dybcio@somainline.org>, Bjorn Andersson <andersson@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>, Frank Rowand <frowand.list@gmail.com> Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Neil Armstrong <neil.armstrong@linaro.org>, devicetree@vger.kernel.org X-Mailer: b4 0.10.1 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_NONE, SPF_HELO_NONE,SPF_PASS 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749647522660075591?= X-GMAIL-MSGID: =?utf-8?q?1749647522660075591?= |
Series |
soc: qcom: Add support for Qualcomm Modem Processing SubSystem DSM memory
|
|
Commit Message
Neil Armstrong
Nov. 16, 2022, 10:16 a.m. UTC
This documents the Qualcomm Modem Processing SubSystem DSM shared memory.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../reserved-memory/qcom,mpss-dsm-mem.yaml | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
Comments
On 16/11/2022 11:16, Neil Armstrong wrote: > This documents the Qualcomm Modem Processing SubSystem DSM shared memory. Do not use "This commit/patch". https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- > .../reserved-memory/qcom,mpss-dsm-mem.yaml | 37 ++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml > new file mode 100644 > index 000000000000..65f37e1356d4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/reserved-memory/qcom,mpss-dsm-mem.yaml#" > +$schema: "http://devicetree.org/meta-schemas/core.yaml#" Drop quotes from above. I know that this and few further pieces came from existing files... > + > +title: Qualcomm Modem Processing SubSystem DSM Memory > + > +description: | > + This binding describes the Qualcomm Modem Processing SubSystem DSM, which serves the Drop "This binding describes" > + purpose of describing the shared memory region used for MPSS remote processors. Entire description seems like not wrapped at 80. > + > +maintainers: > + - Bjorn Andersson <bjorn.andersson@linaro.org> Need to update the address. > + > +allOf: > + - $ref: "reserved-memory.yaml" Drop quotes. > + > +properties: > + compatible: > + const: qcom,mpss-dsm-mem Why do we need dedicated binding and compatible for it instead of using memory-region phandle in the device? > + > +unevaluatedProperties: false Best regards, Krzysztof
On 16/11/2022 13:17, Krzysztof Kozlowski wrote: > On 16/11/2022 11:16, Neil Armstrong wrote: >> This documents the Qualcomm Modem Processing SubSystem DSM shared memory. > > Do not use "This commit/patch". > https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95 > >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- >> .../reserved-memory/qcom,mpss-dsm-mem.yaml | 37 ++++++++++++++++++++++ >> 1 file changed, 37 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml >> new file mode 100644 >> index 000000000000..65f37e1356d4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml >> @@ -0,0 +1,37 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: "http://devicetree.org/schemas/reserved-memory/qcom,mpss-dsm-mem.yaml#" >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" > > Drop quotes from above. > > I know that this and few further pieces came from existing files... Yep sorry, I'll clean it up. > >> + >> +title: Qualcomm Modem Processing SubSystem DSM Memory >> + >> +description: | >> + This binding describes the Qualcomm Modem Processing SubSystem DSM, which serves the > > Drop "This binding describes" > >> + purpose of describing the shared memory region used for MPSS remote processors. > > Entire description seems like not wrapped at 80. > >> + >> +maintainers: >> + - Bjorn Andersson <bjorn.andersson@linaro.org> > > Need to update the address. Argh > >> + >> +allOf: >> + - $ref: "reserved-memory.yaml" > > Drop quotes. > >> + >> +properties: >> + compatible: >> + const: qcom,mpss-dsm-mem > > Why do we need dedicated binding and compatible for it instead of using > memory-region phandle in the device? So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem. Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher, it doesn't represent the MPSS subsystem. In the PAS startup process, the resources are released from APPS once the MPSS subsystem is running, which is not the case with the MPSS DSM where it must be shared during the whole lifetime of the system. Neil > >> + >> +unevaluatedProperties: false > > > Best regards, > Krzysztof >
On 17/11/2022 10:47, Neil Armstrong wrote: >> >>> + >>> +properties: >>> + compatible: >>> + const: qcom,mpss-dsm-mem >> >> Why do we need dedicated binding and compatible for it instead of using >> memory-region phandle in the device? > > So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem. > > Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher, > it doesn't represent the MPSS subsystem. This also does not represent a device. Memory region is not a device, so this is as well not correct representation of hardware. > > In the PAS startup process, the resources are released from APPS once the MPSS subsystem > is running, which is not the case with the MPSS DSM where it must be shared during the whole > lifetime of the system. I don't think that PAS releases the region. I checked the qcom_q6v5_pas.c and there is only ioremap. The device stays loaded thus the memory stays mapped. We have already three of such "memory region devices" and we keep growing it. It's not scalable. Best regards, Krzysztof
On 18/11/2022 11:45, Krzysztof Kozlowski wrote: > On 17/11/2022 10:47, Neil Armstrong wrote: >>> >>>> + >>>> +properties: >>>> + compatible: >>>> + const: qcom,mpss-dsm-mem >>> >>> Why do we need dedicated binding and compatible for it instead of using >>> memory-region phandle in the device? >> >> So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem. >> >> Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher, >> it doesn't represent the MPSS subsystem. > > This also does not represent a device. Memory region is not a device, so > this is as well not correct representation of hardware. I never used the term device so far, but a shared memory region with a platform specific process to share the region between subsystems. > >> >> In the PAS startup process, the resources are released from APPS once the MPSS subsystem >> is running, which is not the case with the MPSS DSM where it must be shared during the whole >> lifetime of the system. > > I don't think that PAS releases the region. I checked the > qcom_q6v5_pas.c and there is only ioremap. The device stays loaded thus > the memory stays mapped. Yes PAS does release the firmware region when the firmware is started, qcom_scm_pas_metadata_release() does that. > > We have already three of such "memory region devices" and we keep > growing it. It's not scalable. If we want to properly describe this, we must then represent the MPSS subsystem and associate this memory region. > > Best regards, > Krzysztof Thanks, Neil >
On 18/11/2022 14:30, neil.armstrong@linaro.org wrote: > On 18/11/2022 11:45, Krzysztof Kozlowski wrote: >> On 17/11/2022 10:47, Neil Armstrong wrote: >>>> >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: qcom,mpss-dsm-mem >>>> >>>> Why do we need dedicated binding and compatible for it instead of using >>>> memory-region phandle in the device? >>> >>> So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem. >>> >>> Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher, >>> it doesn't represent the MPSS subsystem. >> >> This also does not represent a device. Memory region is not a device, so >> this is as well not correct representation of hardware. > > I never used the term device so far, but a shared memory region with a platform > specific process to share the region between subsystems. Yes, but you create a device in patch #2 for this binding. > >> >>> >>> In the PAS startup process, the resources are released from APPS once the MPSS subsystem >>> is running, which is not the case with the MPSS DSM where it must be shared during the whole >>> lifetime of the system. >> >> I don't think that PAS releases the region. I checked the >> qcom_q6v5_pas.c and there is only ioremap. The device stays loaded thus >> the memory stays mapped. > Yes PAS does release the firmware region when the firmware is started, > qcom_scm_pas_metadata_release() does that. Indeed, I see it now. > >> >> We have already three of such "memory region devices" and we keep >> growing it. It's not scalable. > > If we want to properly describe this, we must then represent the MPSS subsystem > and associate this memory region. I don't see why. None of devices in your DTS reference this memory region, so it is purely to keep it mapped for Modem, right? In such case I still do not get why PAS/PIL, who starts and stops the remote processor, could not prepare the memory and share it with modem. The point is that this memory region is nothing special and does not deserve its own compatible. We keep adding here compatibles to fulfill some Linux implementation specifics, don't we? Best regards, Krzysztof
On 18/11/2022 15:03, Krzysztof Kozlowski wrote: > On 18/11/2022 14:30, neil.armstrong@linaro.org wrote: >> On 18/11/2022 11:45, Krzysztof Kozlowski wrote: >>> On 17/11/2022 10:47, Neil Armstrong wrote: >>>>> >>>>>> + >>>>>> +properties: >>>>>> + compatible: >>>>>> + const: qcom,mpss-dsm-mem >>>>> >>>>> Why do we need dedicated binding and compatible for it instead of using >>>>> memory-region phandle in the device? >>>> >>>> So like rmtfs, this memory zone is shared between APPS and the MPSS subsystem. >>>> >>>> Like rmtfs it makes no sense to link it to the MPSS PAS, since it's only a launcher, >>>> it doesn't represent the MPSS subsystem. >>> >>> This also does not represent a device. Memory region is not a device, so >>> this is as well not correct representation of hardware. >> >> I never used the term device so far, but a shared memory region with a platform >> specific process to share the region between subsystems. > > Yes, but you create a device in patch #2 for this binding. Implementation details are out of scope here. > >> >>> >>>> >>>> In the PAS startup process, the resources are released from APPS once the MPSS subsystem >>>> is running, which is not the case with the MPSS DSM where it must be shared during the whole >>>> lifetime of the system. >>> >>> I don't think that PAS releases the region. I checked the >>> qcom_q6v5_pas.c and there is only ioremap. The device stays loaded thus >>> the memory stays mapped. >> Yes PAS does release the firmware region when the firmware is started, >> qcom_scm_pas_metadata_release() does that. > > Indeed, I see it now. > >> >>> >>> We have already three of such "memory region devices" and we keep >>> growing it. It's not scalable. >> >> If we want to properly describe this, we must then represent the MPSS subsystem >> and associate this memory region. > > I don't see why. None of devices in your DTS reference this memory > region, so it is purely to keep it mapped for Modem, right? In such case > I still do not get why PAS/PIL, who starts and stops the remote > processor, could not prepare the memory and share it with modem. OK you've got a point, but this is still an implementation detail. I got some more background about why this memory zone appeared, before it was including in the modem reserved-memories, but for flexibility reasons this is now in the hands of the APPS runtime (linux) to setup this memory zone and share it to the MPSS subsystem. So the only requirement for the PAS is to make sure this zone is shared before starting the startup process, not to actually do the share setup. The zone will need to be shared whatever the PAS state is (probe, startup, remove, ...). > > The point is that this memory region is nothing special and does not > deserve its own compatible. We keep adding here compatibles to fulfill > some Linux implementation specifics, don't we? Yes this memory region is now special since it has to be shared explicitly. > > Best regards, > Krzysztof > Thanks, Neil
On 23/11/2022 11:19, neil.armstrong@linaro.org wrote: >>>> We have already three of such "memory region devices" and we keep >>>> growing it. It's not scalable. >>> >>> If we want to properly describe this, we must then represent the MPSS subsystem >>> and associate this memory region. >> >> I don't see why. None of devices in your DTS reference this memory >> region, so it is purely to keep it mapped for Modem, right? In such case >> I still do not get why PAS/PIL, who starts and stops the remote >> processor, could not prepare the memory and share it with modem. > > OK you've got a point, but this is still an implementation detail. > > I got some more background about why this memory zone appeared, before it > was including in the modem reserved-memories, but for flexibility reasons > this is now in the hands of the APPS runtime (linux) to setup this memory > zone and share it to the MPSS subsystem. > > So the only requirement for the PAS is to make sure this zone is shared > before starting the startup process, not to actually do the share setup. > > The zone will need to be shared whatever the PAS state is (probe, startup, remove, ...). I don't understand here. The memory region should be shared before remote processor start or before the PAS probe? If the second, why? What if your driver probes a bit later - after PAS probe? Then all is lost... Best regards, Krzysztof
On 24/11/2022 14:57, Krzysztof Kozlowski wrote: > On 23/11/2022 11:19, neil.armstrong@linaro.org wrote: >>>>> We have already three of such "memory region devices" and we keep >>>>> growing it. It's not scalable. >>>> >>>> If we want to properly describe this, we must then represent the MPSS subsystem >>>> and associate this memory region. >>> >>> I don't see why. None of devices in your DTS reference this memory >>> region, so it is purely to keep it mapped for Modem, right? In such case >>> I still do not get why PAS/PIL, who starts and stops the remote >>> processor, could not prepare the memory and share it with modem. >> >> OK you've got a point, but this is still an implementation detail. >> >> I got some more background about why this memory zone appeared, before it >> was including in the modem reserved-memories, but for flexibility reasons >> this is now in the hands of the APPS runtime (linux) to setup this memory >> zone and share it to the MPSS subsystem. >> >> So the only requirement for the PAS is to make sure this zone is shared >> before starting the startup process, not to actually do the share setup. >> >> The zone will need to be shared whatever the PAS state is (probe, startup, remove, ...). > > I don't understand here. The memory region should be shared before > remote processor start or before the PAS probe? If the second, why? What > if your driver probes a bit later - after PAS probe? Then all is lost... After offline discussions, I'll associate the DSM memory zone to the PAS MPSS loader instead to make sure the zone is shared before startup. Thanks, Neil > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml new file mode 100644 index 000000000000..65f37e1356d4 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,mpss-dsm-mem.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reserved-memory/qcom,mpss-dsm-mem.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Modem Processing SubSystem DSM Memory + +description: | + This binding describes the Qualcomm Modem Processing SubSystem DSM, which serves the + purpose of describing the shared memory region used for MPSS remote processors. + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: qcom,mpss-dsm-mem + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + mpss-dsm@86700000 { + compatible = "qcom,mpss-dsm-mem"; + reg = <0x86700000 0xe0000>; + no-map; + }; + };