Re: Question about Iris SID override assertion on Yoga Slim 7x

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

Hello Birk,

On 9/14/2026 1:17 AM, Birk Skyum wrote:
> 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.

Same failure was seen once in windows based X1E80100, and i was informed 
that doing an explicit GDSC (vcodec) power on before doing a warm boot 
i.e iris_vpu_boot_firmware() helped the case in windows. I have checked, 
in iris, iris_vpu_power_on() would get the vcodec GDSC on before 
iris_vpu_boot_firmware().

I am gathering more info on SID override configuration part.

+ing Renjiang who is helping to debug this issue along with me.

> 
> 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.

Could you please share details on the FFmpeg test and the local fix ? We 
will repro this locally to get better insight of this issue.

> 
> 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

Regards,
Vikash