All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan.gerhold@linaro.org>
To: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Jingyi Wang <jingyi.wang@oss.qualcomm.com>,
	Bartosz Golaszewski <brgl@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time
Date: Fri, 9 Oct 2026 16:20:58 +0200	[thread overview]
Message-ID: <asj4Sgsjw5xNXNLb@linaro.org> (raw)
In-Reply-To: <20261006033550.2726451-2-shengchao.guo@oss.qualcomm.com>

On Tue, Oct 06, 2026 at 11:35:49AM +0800, Shawn Guo wrote:
> For early_boot subsystems, probe unconditionally marks the rproc
> RPROC_DETACHED and qcom_pas_attach() discovers from SMP2P whether the
> bootloader actually started the remote. If it did not, attach sets the
> state back to RPROC_OFFLINE and fails, expecting the core to boot the
> firmware instead. The core does not do that: rproc_boot() treats the
> attach failure as fatal and the remote is never started.
> 
> This is hit on Nord with firmware where XBL no longer brings ADSP out
> of reset. The remote never publishes its inbound SMP2P entries, so the
> very first state read fails (debug print below) and the ADSP stays down:
> 
>   qcom_q6v5_pas 4c00000.remoteproc: Failed to get fatal_irq state: -19
>   remoteproc remoteproc0: can't attach to rproc adsp: -19
> 
> The ready, stop-ack and sysmon shutdown-ack signals cannot change while
> Linux has not yet interacted with the remote, so there is no reason to
> defer the decision to attach time. Check them in probe and only mark
> the rproc RPROC_DETACHED when the remote is up and has not been asked
> to stop; otherwise leave it RPROC_OFFLINE so the regular firmware boot
> path is taken. The ready state is read first so that a missing SMP2P
> entry -ENODEV is treated as "not running" before sysmon is queried.
> 
> qcom_pas_attach() keeps only the fatal check, since that is the one
> signal that has to be acted upon once the rproc is attached.
> 
> Assisted-by: LLM
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
>  drivers/remoteproc/qcom_q6v5_pas.c | 64 +++++++++++++++---------------
>  1 file changed, 33 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 2e1e39826ffa..8f3d45c604c9 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -550,9 +550,7 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
>  static int qcom_pas_attach(struct rproc *rproc)
>  {
>  	struct qcom_pas *pas = rproc->priv;
> -	bool ready_state;
>  	bool crash_state;
> -	bool stop_state;
>  	int ret;
>  
>  	pas->q6v5.handover_issued = true;
> @@ -570,42 +568,46 @@ static int qcom_pas_attach(struct rproc *rproc)
>  		goto disable_running;
>  	}
>  
> -	ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
> -				    IRQCHIP_STATE_LINE_LEVEL, &stop_state);
> -	if (ret)
> -		goto disable_running;
> -
> -	if (stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
> -		dev_info(pas->dev, "Subsystem found stop state set. Falling back to start.\n");
> -		goto unroll_attach;
> -	}
> -
> -	ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> -				    IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> -	if (ret)
> -		goto disable_running;
> -
> -	if (unlikely(!ready_state)) {
> -		/*
> -		 * The bootloader may not support early boot, mark the state as
> -		 * RPROC_OFFLINE so that the PAS driver can load the firmware and
> -		 * start the remoteproc.
> -		 */
> -		dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
> -		goto unroll_attach;
> -	}
> -
>  	return 0;
>  
> -unroll_attach:
> -	pas->rproc->state = RPROC_OFFLINE;
> -	ret = -EINVAL;
>  disable_running:
>  	pas->q6v5.running = false;
>  
>  	return ret;
>  }
>  
> +/*
> + * The bootloader may or may not have started the subsystem. Inspect the
> + * SMP2P state, which is static until Linux interacts with the remote, to
> + * decide whether to attach or to load and start the firmware.
> + */
> +static bool qcom_pas_is_running(struct qcom_pas *pas)
> +{
> +	bool ready_state;
> +	bool stop_state;
> +	int ret;
> +
> +	/*
> +	 * Check ready first: if the remote never published its SMP2P
> +	 * entries the state read fails with -ENODEV.
> +	 */
> +	ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> +				    IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> +	if (ret || !ready_state) {
> +		dev_info(pas->dev, "Subsystem not running. Falling back to start.\n");
> +		return false;
> +	}
> +
> +	ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
> +				    IRQCHIP_STATE_LINE_LEVEL, &stop_state);
> +	if (ret || stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
> +		dev_info(pas->dev, "Subsystem found stop state set. Falling back to start.\n");
> +		return false;
> +	}

Nitpick: Both of these messages are a bit imprecise. desc->early_boot
does not necessarily imply desc->auto_boot, so they may just be marked
as offline and not automatically started.

But you just moved this code and I don't think it's worth resending just
to polish these messages a bit more. :-)

In any case:

Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>

Thanks,
Stephan

  reply	other threads:[~2026-10-09 14:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  3:35 [PATCH 0/2] remoteproc: qcom: pas: Fix early_boot attach for not running and crashed remotes Shawn Guo
2026-10-06  3:35 ` [PATCH 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time Shawn Guo
2026-10-09 14:20   ` Stephan Gerhold [this message]
2026-10-11  2:01     ` Shawn Guo
2026-10-06  3:35 ` [PATCH 2/2] remoteproc: qcom: pas: Don't fail attach if the remote has crashed Shawn Guo
2026-10-09 14:38   ` Stephan Gerhold
2026-10-11  2:04     ` Shawn Guo

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=asj4Sgsjw5xNXNLb@linaro.org \
    --to=stephan.gerhold@linaro.org \
    --cc=andersson@kernel.org \
    --cc=brgl@kernel.org \
    --cc=jingyi.wang@oss.qualcomm.com \
    --cc=konradybcio@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=shengchao.guo@oss.qualcomm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.