[Dragon Q6A] Venus H.264 encoder hangs in uninterruptible-sleep — firmware never requested (kernel 6.18.2-3-qcom)

[jason-dgio]

On a Radxa Dragon Q6A (QCS6490) running the stock Radxa image with kernel 6.18.2-3-qcom, the Venus video encoder enumerates correctly but any actual encode attempt hangs in kernel uninterruptible-sleep. The driver appears to never call request_firmware for Venus — dmesg shows the binding message but no firmware-load activity, success or failure.

Environment

• Board: Radxa Dragon Q6A (QCS6490, eMMC Module V1.2)
• Image: shipped Radxa Ubuntu 24.04 (fresh boot today)
• Kernel: Linux dragon-q6a 6.18.2-3-qcom #1 SMP PREEMPT ...
• Venus modules: venus_core, venus_enc, venus_dec all loaded
• Firmware dirs: /lib/firmware/qcom/venus-{1.8,4.2,5.2,5.4,6.0}/ contain only .zst-compressed venus.mbn.zst (Jan 2026 dated)

What works

• v4l2-ctl --device /dev/video1 --info reports Card type: Qualcomm Venus video encoder
• --list-formats-ext lists H.264 + HEVC on CAPTURE queue
• Opening the device returns successfully

What fails

Any of the following hangs in D-state indefinitely (cannot be killed with SIGKILL or `timeout`):

```bash
ffmpeg -f lavfi -i testsrc2=size=640x480:rate=15 -t 1 \
-vf format=nv12 -c:v h264_v4l2m2m -b:v 1M -y /tmp/v.h264

gst-launch-1.0 -e videotestsrc num-buffers=30 \
! "video/x-raw,format=NV12,width=640,height=480,framerate=30/1" \
! v4l2h264enc device=/dev/video1 \
! filesink location=/tmp/v.h264
```

Smoking gun: no firmware load attempt

`sudo dmesg -c >/dev/null` followed by an encode attempt — dmesg afterward shows nothing Venus-related. By contrast the WiFi chip's `aic_load_firmware` is verbose about every file it pulls. The Venus driver appears to not be reaching the firmware-request stage at all.

What I tried

1. Decompressed all `/lib/firmware/qcom/venus-*/venus.mbn.zst` → `venus.mbn` (since `CONFIG_FW_LOADER_COMPRESS_ZSTD` is not set per `zcat /proc/config.gz | grep FW_LOADER`).
2. Symlinked `venus.mdt` → `venus.mbn` in each dir.
3. Reloaded the venus modules (failed silently because /dev/video1 was still open by udev).
4. Full reboot.

No change after any of the above. The driver still binds, /dev/video1 still enumerates, encode attempts still hang, dmesg still empty for Venus.

Expected

Either firmware loads successfully (dmesg shows the load), or it fails visibly with a `request_firmware ... failed` line so we know which path to debug.

Hypothesis

The Venus probe path in this kernel build may not be wired to call `request_firmware` at all — the lazy-load on stream-start path appears to be skipping the firmware acquisition step entirely.

Happy to provide the kernel build config, full dmesg, or run any diagnostic. The board is on the bench.

[jason-dgio]

Additional diagnosis from our Q6A this morning — sharing in case it helps narrow this down.

Reproduction is consistent

$ ffmpeg -loglevel warning \
  -f lavfi -i 'testsrc=duration=1:size=1280x720:rate=30' \
  -pix_fmt nv12 -c:v h264_v4l2m2m -b:v 2M /tmp/out.h264 -y

→ ffmpeg enters kernel D-state on the V4L2 streaming path; timeout -s KILL cannot reap it, has to wait ~minutes for the kernel to release.

Kernel state during the hang — completely silent

Cleared the dmesg ring before triggering, ran dmesg -w > /tmp/cap.log in parallel. Zero kernel messages produced during the failure. No errors, no traces, no completion timeouts. The driver hangs without emitting anything.

This rules out a simple request_firmware failure (which would log fail to load video firmware) and suggests the hang is in an hfi_session_* wait_for_completion that never fires.

Single venus message at boot

The entire kernel log contains exactly one Venus line:

[    0.849237] qcom-venus aa00000.video-codec: non legacy binding

So probe completed past drivers/media/platform/qcom/venus/pm_helpers.c:975 (in core_get_v4) without error. v4l2 enumeration works, encoder capabilities list correctly (H264 + HEVC, 128×128–8192×8192).

DT binding observation

The Q6A's device tree binds the Venus IP using compatible = "qcom,sc7280-venus":

$ cat /proc/device-tree/soc@0/video-codec@aa00000/compatible
qcom,sc7280-venus

There is no qcom,qcs6490-venus or qcom,sm7325-venus compatible in upstream (v6.18 drivers/media/platform/qcom/venus/core.c). Radxa is reusing the sc7280 binding because QCS6490 shares the Iris2 IP family — but the matching resources struct (sc7280_res) assumes sc7280-specific clocks, power domains, and .fwname = "qcom/vpu-2.0/venus.mbn", which may not be a clean match for QCS6490's actual peripheral wiring.

Worth checking whether the host-side init handshake (HFI v6xx session-init) is silently incompatible because of clock/regulator differences between the two SoCs that don't surface as a probe-time error.

Environment

• Board: Radxa Dragon Q6A (QCS6490, eMMC Module V1.2)
• Kernel: Linux dragon-q6a 6.18.2-3-qcom #1 SMP PREEMPT aarch64
• Image: shipped Radxa Ubuntu 24.04 (fresh boot)
• Venus modules: venus_core, venus_enc, venus_dec all loaded (autoload at probe)
• Firmware on disk: /lib/firmware/qcom/vpu-2.0/venus.mbn.zst (zstd-compressed; uncompressed not present)
• /lib/firmware/qcom/venus-6.0/venus.mbn does exist uncompressed (1.7 MB, Jan 2026)

Happy to run any further diagnostic (strace on the encode, debugfs dumps, instrumented module rebuild) if it would help triage.