The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Bjorn Andersson <andersson@kernel.org>
To: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Mathieu Poirier <mathieu.poirier@linaro.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	 linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
Date: Sun, 5 Jul 2026 17:26:22 -0500	[thread overview]
Message-ID: <akrWGWtPpIJhL0pF@baldur> (raw)
In-Reply-To: <20260703-glymur-soccp-v4-1-b706c4c9b3e2@oss.qualcomm.com>

On Fri, Jul 03, 2026 at 05:31:11AM -0700, Ananthu C V wrote:
> Most Qualcomm platforms feature Gunyah hypervisor, which typically
> handles Stage 2 IOMMU configuration.

This statement is true, but the IOMMU isn't involved in the interaction
between OS and TZ, so it doesn't add value to your problem description.

> Additionally, SHM bridge setup is required to enable memory protection
> for both remoteproc metadata and its memory regions.

"Additionally"? Isn't this the entire problem?

> When the aforementioned hypervisor is absent, the operating system
> must perform these configurations instead.

Please rephrase these three sentences to make sure we have a clear
problem description.

Then, at this point in the text you have established the problem, so
break the paragraph with an empty line.

> We've been relying on the iommu property being present for this, but
> for remoteprocs that are already running like SoCCP the mappings are
> already in place, and any attempt to recreate them while active would
> lead to smmu faults and a non-functional remoteproc.

This is a significant detail. Please expand the description around
"attempt to recreate them while active" to ensure that it's clear to the
reader what the problem (what does it mean that mappings are already in
place).

Then another </p><p> here, as we're once again in need of some breathing
and thinking-room.

> Fix this by adding a needs_tzmem
> flag which ensures tzmem and SHM bridge setup is performed independent to
> the iommu property being present.

"flag which ensures...", the flag doesn't ensure anything, it is
propagates as an alternative trigger to the PAS helpers to ensure that
the shmbridge is established.

Regards,
Bjorn

> 
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> ---
>  drivers/remoteproc/qcom_q6v5_pas.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 60a4337d9e51..cd7273fbcf98 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -61,6 +61,7 @@ struct qcom_pas_data {
>  	bool region_assign_shared;
>  	int region_assign_vmid;
>  	bool early_boot;
> +	bool needs_tzmem;
>  };
>  
>  struct qcom_pas {
> @@ -914,8 +915,8 @@ static int qcom_pas_probe(struct platform_device *pdev)
>  		goto remove_ssr_sysmon;
>  	}
>  
> -	pas->pas_ctx->use_tzmem = rproc->has_iommu;
> -	pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
> +	pas->pas_ctx->use_tzmem = desc->needs_tzmem || rproc->has_iommu;
> +	pas->dtb_pas_ctx->use_tzmem = desc->needs_tzmem || rproc->has_iommu;
>  
>  	if (desc->early_boot)
>  		pas->rproc->state = RPROC_DETACHED;
> @@ -1657,8 +1658,27 @@ static const struct qcom_pas_data kaanapali_soccp_resource = {
>  	.early_boot = true,
>  };
>  
> +static const struct qcom_pas_data glymur_soccp_resource = {
> +	.crash_reason_smem = 656,
> +	.firmware_name = "soccp.mbn",
> +	.dtb_firmware_name = "soccp_dtb.mbn",
> +	.pas_id = 51,
> +	.dtb_pas_id = 0x41,
> +	.proxy_pd_names = (char*[]){
> +		"cx",
> +		"mx",
> +		NULL
> +	},
> +	.ssr_name = "soccp",
> +	.sysmon_name = "soccp",
> +	.auto_boot = true,
> +	.early_boot = true,
> +	.needs_tzmem = true,
> +};
> +
>  static const struct of_device_id qcom_pas_of_match[] = {
>  	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
> +	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },
>  	{ .compatible = "qcom,kaanapali-soccp-pas", .data = &kaanapali_soccp_resource },
>  	{ .compatible = "qcom,milos-adsp-pas", .data = &sm8550_adsp_resource },
>  	{ .compatible = "qcom,milos-cdsp-pas", .data = &milos_cdsp_resource },
> 
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2026-07-05 22:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 12:31 [PATCH v4 0/3] Add remoteproc PAS loader for SoCCP on Glymur DT Ananthu C V
2026-07-03 12:31 ` [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation Ananthu C V
2026-07-03 12:44   ` Krzysztof Kozlowski
2026-07-03 14:35     ` Ananthu C V
2026-07-03 14:47       ` Krzysztof Kozlowski
2026-07-05 22:26   ` Bjorn Andersson [this message]
2026-07-06  6:50     ` Ananthu C V
2026-07-03 12:31 ` [PATCH v4 2/3] arm64: dts: qcom: fix SoCCP memory mappings for Glymur Ananthu C V
2026-07-05 22:27   ` Bjorn Andersson
2026-07-03 12:31 ` [PATCH v4 3/3] arm64: dts: qcom: add SoCCP DT node " Ananthu C V
2026-07-05 22:41   ` Bjorn Andersson
2026-07-06  6:52     ` Ananthu C V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akrWGWtPpIJhL0pF@baldur \
    --to=andersson@kernel.org \
    --cc=ananthu.cv@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox