Question about Iris SID override assertion on Yoga Slim 7x

[Birk Skyum <birk.skyum@pm.me>]

Hi Vikash and Dikshita,

I'm testing Iris video decoding on a Lenovo Yoga Slim 7x (83ED, X1E80100).
This is a request for guidance on a firmware assertion. It currently
reproduces on a modified test stack, and I'm working on reducing it to
an unmodified-driver reproduction.

After repeated runtime-suspend/resume cycles, VP9 startup intermittently
hits this firmware assertion before initial stream settings or CAPTURE START:

  VenusCoreCtrl_InitSS(506): un-expected SID override configuration
  WaitForHWidle(462): VENUS is idle, no HW is running
  assert_loop(500): FW Assertion - venusCoreController.c:507

The first HFI error is 0x05000003. The SFR names the same source line.
Later venus_c2_parsing.c:1550 assertions follow automatic recovery; they
are not the original failure.

Could you clarify what the SID override check expects on X1E80100, and
whether there is a known firmware, secure-firmware, or resume-sequencing
requirement I should check? Which diagnostics would help distinguish a
driver sequencing problem from a firmware requirement? I can test a
targeted diagnostic or patch.

The firmware is qcom/x1e80100/LENOVO/83ED/qcvss8380.mbn from
linux-firmware-qcom 20260810-2:

  video-firmware.3.1-e5aea20c64cb6df9a1c9be99e206053b36424939
  PROD, build May 9 2024
  SHA256 3456a15e01528c2ba2957ef2b78daefd875841b262dc02f0c3bb03c33cba657f

That hash matches the current linux-firmware main file. The BIOS is
NHCN62WW, dated 12/02/2025. The device tree lists qcom,x1e80100-iris with
the qcom,sm8550-iris fallback.

The test repeatedly decodes the same synthetic 1280x720 VP9 clip, 120
frames at normal speed, closes the decoder, verifies runtime_status is
suspended for 100 seconds, then starts again. FFmpeg is 9.0.1 with a local
fix to requeue empty non-LAST ERROR capture buffers. Successful runs
match every decoded frame against software decoding.

On one cold boot, three 100-second idle trials with power/control=on
passed. After restoring auto, two suspended-idle trials passed and the
third failed. On another boot with auto throughout, two passed and the
third failed. A separate codec guard removed an unnecessary AV1-only
partial buffer from VP9; its warning disappeared, but the fourth
suspended-idle trial still hit the same SID assertion. These comparisons
do not establish runtime PM as the cause or keeping power on as a fix.

This is a modified test stack, not a pristine-mainline reproduction. The
kernel is 7.2.0-1.1-aarch64-ARCH-camera1, with camera patches. The in-tree
Iris and video-clock sources were built as external modules. Iris also
has experimental initial-CAPTURE deferral and pre-start buffer ownership
changes, a bounded HFI/SFR diagnostic, and Renjiang Han's firmware-logging
patch with an early debug-queue drain to retain the pre-assertion messages.
The failing session receives OPEN acknowledgement and its first compressed
input before the fatal error. No looping or seek is reached.

Testing stops at the first failure and resumes only after a clean shutdown
and physical power-on. No clock-module reloads are involved. I can provide
the synthetic clip, exact source changes and filtered HFI trace if useful.

Thanks,
Birk