The late attach support for early_boot subsystems has two problems.
1) A remote that the bootloader did not start is never booted. The
checks for that case live in qcom_pas_attach(), which marks the rproc
RPROC_OFFLINE and fails, but the core treats the failure as fatal and
never loads the firmware. This shows up on Nord, where newer XBL
firmware for the IoT variant leaves ADSP in reset for Linux to boot:
remoteproc remoteproc0: can't attach to rproc adsp: -19
Patch 1 moves the ready/stop-ack/shutdown-ack checks into probe, as
these signals are static until Linux interacts with the remote, and
only marks the rproc RPROC_DETACHED if the remote is running.
2) A remote found crashed at attach is recovered on top of the state the
failed attach has already unwound. Recovery leaves the rproc running
with a zero power refcount, so a following sysfs stop is a no-op and
start boots the firmware again on the running remote. Patch 2 lets
the attach succeed after reporting the crash, as the fatal interrupt
handler does, so recovery runs from the attached state.
This replaces the earlier patch dropping the early_boot flag from Nord
ADSP, following Konrad's and Stephan's comments [1]. With this series
the flag is kept, since the Nord Auto variant still has ADSP started by
XBL.
Changes for v2:
- Reword the "not attaching" info messages, as early_boot doesn't imply
auto_boot
- Factor crash handling out of q6v5_fatal_interrupt() into
qcom_q6v5_report_fatal() and use it in qcom_pas_attach() so the SMEM
crash reason is logged
- Link to v1:
https://lore.kernel.org/all/[email protected]/
[1]
https://lore.kernel.org/r/[email protected]/
Shawn Guo (2):
remoteproc: qcom: pas: Decide early_boot attach at probe time
remoteproc: qcom: pas: Don't fail attach if the remote has crashed
drivers/remoteproc/qcom_q6v5.c | 22 ++++++---
drivers/remoteproc/qcom_q6v5.h | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 71 ++++++++++++++++--------------
3 files changed, 56 insertions(+), 38 deletions(-)
--
2.43.0
