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

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

On 9/17/2026 4:50 PM, Vikash Garodia wrote:
> 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

Could you please try the usecase with the fix

https://lore.kernel.org/all/20260924-vpu_hwmode_fix-v1-1-531498f3499a@oss.qualcomm.com/

Regards,
Vikash

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