Re: [PATCH] remoteproc: qcom_q6v5_pas: Drop early_boot flag for Nord ADSP

[Shawn Guo]

On Thu, Oct 01, 2026 at 10:42:39AM +0200, Konrad Dybcio wrote:
> On 9/30/26 4:07 AM, Shawn Guo wrote:
> > Qualcomm NHLOS team changes XBL for Nord IOT/Embedded variant, leaving
> > ADSP to be powered up by Linux remoteproc, so that Nord IQ10 Qualcomm
> > Linux (QLI) behavior gets aligned with IQ8/9. Drop early_boot flag from
> > Nord ADSP for that purpose.
> > 
> > Signed-off-by: Shawn Guo <shengchao.guo@xxxxxxxxxxxxxxxx>
> > ---
> 
> What happens if this patch is absent?

ADSP never comes up:

  remoteproc remoteproc0: attaching to adsp
  remoteproc remoteproc0: can't attach to rproc adsp: -19

Since XBL no longer boots ADSP, the remote never publishes its SMP2P
inbound item. The smp2p entry stays unmapped, and irq_get_irqchip_state()
on fatal_irq returns -ENODEV. qcom_pas_attach() treats that as a hard
error rather than falling back to a firmware boot.

Even the existing fallback (ready bit clear -> RPROC_OFFLINE) doesn't
work: rproc_boot() takes the attach branch, sees the error and returns
without loading firmware.

> 
> When the early_boot path was first introduced I was really hoping
> that this behavior could be made unconditional and Linux would
> figure out if the rproc may be active by virtue of it sending
> back signals or not, unfortunately that hasn't made it into the
> tree..

The difficulty is with the positive signal. As Stephan pointed out [1],
the ready bit is not cleared when the remote is stopped or force-shutdown,
so a stop followed by rmmod/modprobe of qcom_q6v5_pas makes the driver
attach to a remote that is not running. Without ping-pong or a PAS query
for the remote state, I don't think we can reliably say that a remote
*is* running.

The negative signal is reliable though. The -ENODEV from
irq_get_irqchip_state() means the remote has never populated its SMP2P
entry since cold boot, so it cannot be running. We can fall back to a
firmware boot in that case. early_boot then becomes a hint that the
bootloader *may* have started the remote, which matches Nord ADSP:
it is started by XBL on the Auto variant and by Linux remoteproc on
the IoT variant.

I'll drop this patch and send two patches instead:

- remoteproc: core: continue to the firmware boot path when .attach()
  leaves the rproc in RPROC_OFFLINE
- remoteproc: qcom: pas: treat -ENODEV from the SMP2P state read as
  "not running" and fall back to start

With those, Nord ADSP keeps early_boot and I've tested it with both XBL
variants. With the old XBL it attaches as before; with the new one
it falls back to loading firmware.

Shawn

[1] https://lore.kernel.org/all/ahBG6jKYdSAboWjs@xxxxxxxxxx/