Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Bryan O'Donoghue <bod@kernel.org>]

On 20/07/2026 13:22, Kirill Ermolitskiy wrote:
> Hi,
> 
> On a mainline port of the Xiaomi 11 Lite 5G NE (sm7325-xiaomi-lisa,
> SM7325 "kodiak", sc7280-compatible venus, kernel 7.1.2, postmarketOS),
> the Venus decoder works fine (H264/VP9/HEVC/MPEG2 via v4l2 m2m), but
> executing any encoder job instantly hard-resets the SoC below the
> kernel. I've spent considerable effort narrowing this down and I
> believe I've hit the limit of what can be done without wrapper/GDSC
> documentation.
> 
> Reproducer (100%):
> 
>    ffmpeg -f lavfi -i testsrc2=size=176x144:rate=10 -vf format=nv12 \
>      -c:v h264_v4l2m2m -b:v 100k -t 5 /tmp/e.mp4
> 
> With venus dyndbg + custom HFI tracing on UART, the full session
> negotiates cleanly: SYS_INIT, SESSION_INIT (acked), all
> SET_PROPERTY/SET_BUFFERS (accepted), LOAD_RESOURCES (acked), START
> (acked), 4x ETB. The SoC dies the instant the first FTB is issued and
> the engine starts executing — no SYS_ERROR, no EBD/FBD, no SMMU fault,
> nothing from the kernel. XBL log after reboot shows "PM: Reset by
> PSHOLD / Warm Reset", i.e. a TZ/secure-level reset. HEVC dies
> identically (engine-level, not codec-specific).
> 
> What I've verified/excluded (all cross-checked against the downstream
> yupik tree):
> - memory-region (0x8b200000/0x500000), SMMU SID (0x2180/0x20), CP
> ranges (cp 0x0+0x25800000, nonpixel 0x1000000+0x24800000), clock set,
> GDSC offsets (0x3004/0x2004): all match downstream.
> - Firmware: vendor vpu20_1v.mbn, Xiaomi-signed (Xiaomi Root CA /
> Attestation CA in the cert chain), reproduced with two firmware stacks
> (old and HyperOS OS2.0.8.0 coherent TZ+vpu pair). Venus hw version
> 6.40.a.
> - Reproduced identically with the iris driver (sc7280 platform data) —
> two independent implementations, same silent reset.
> - Encoder scratch buffer sizes x4: no change. Runtime PM pinned: no change.
> 
> The interesting part is the power matrix around vcodec_control_v4():
> 
> 1. Stock (dev_pm_genpd_set_hwmode, HW_CTRL_TRIGGER on mvs0_gdsc):
> set_hwmode returns 0, engine powers up on first frame -> instant
> PSHOLD reset.
> 2. Forced legacy path: WRAPPER_VCODEC0_MMCC_POWER_STATUS BIT(1) never
> asserts (readl_poll_timeout -110, register reads 0x0). No crash — but
> ignoring the timeout shows the engine never leaves clamps: session
> runs to FTB, zero EBD/FBD, fw eventually non-idle ("wait for cpu and
> video core idle fail").
> 3. GDSC forced SW-mode via genpd, or ALWAYS_ON: same as (2) — rail up,
> engine clamped, no execution, no crash.
> 4. video_cc_xo_clk (0x7018 branch + 0x7000 RCG): missing entirely from
> mainline videocc-sc7280.c, downstream marks it CLK_IS_CRITICAL. Ported
> it (confirmed on at 19.2 MHz in clk_summary): no behavioral change in
> any mode.
> 5. Dropping en_rest_wait_val/en_few_wait_val/clk_dis_wait_val from
> mvs0_gdsc (keeping XBL defaults): still resets, but behavior became
> nondeterministic across runs (one run showed a msg-queue response
> after FTB before dying) — smells like power-ramp timing.
> 
> So: the encoder engine only actually executes when the MVS0 GDSC is
> under HW control, and that execution/power-up hard-resets the SoC;
> every software-controlled arrangement leaves the engine clamped (MMCC
> handshake never completes). Downstream (msm-vidc + gdsc-regulator with
> qcom,support-hw-trigger) uses hw-trigger on the same silicon and
> encodes fine under Android, so the hardware is capable — something in
> the mainline hw-trigger power-up sequencing differs fatally on kodiak.
> 
> Questions for people with wrapper/GDSC documentation:
> - What does the hw-triggered MVS0 power-up require on kodiak/sc7280
> beyond what mainline gdsc.c + venus do today (AON config? NoC LPI
> handshake? different GDSCR sequencing)?
> - Is the sm7280_reg_preset ({0xb0088, 0}) sufficient for this part, or
> does downstream program additional AON/wrapper registers before
> encode?
> 
> I can test patches quickly (UART attached, one-command reproducer,
> full HFI traces of both healthy decode and dying encode sessions
> available on request).
> 
> Thanks,
> Del'aRun

Quite likely to be operating point failure i.e. not ramping voltage to 
match clock.

Anyway we're doing a new kernel release so I'll try to replicate on 8250 
which is ~ the same silicon.

---
bod