[PATCH v11 00/10] Enable video decoder & encoder for MT8189

[zoan37]

Hi Kyrie,

Thanks for the series. Test report from an MT8189 Chromebook (Lenovo
IdeaPad Slim 3 Chromebook, board "quigon" of the skywalker family):
next-20261008 with the other posted MT8189 series and this board's DT,
plus MT8196 decoder v8, MT8196 encoder v8 and this v11 on top, and
linux-firmware's mediatek/mt8189/scp.img (FW version e3c0782 Jan 30
2026; identical to the image ChromeOS ships).

VP9 decode: 240/240 frames bit-exact (1080p test stream through
libva-v4l2-request, checked against software decoding).

H.264 decode: the SCP hangs (watchdog timeout) and every frame is wrong.
The firmware has 'reserved' at the end of struct
vdec_h264_slice_info_ext (after crc[8]), not after 'timeout'; with the
current layout every slice parameter lands 8 bytes early. With only
this change on top of v11, H.264 decodes 240/240 frames bit-exact:

  	u16 timeout;
 -	u32 reserved;
  	u64 vdec_fb_va;
  	u32 crc[8];
 +	u32 reserved;
  };

I don't know which layout the MT8188/MT8195 firmware uses, so this may
need to depend on the platform or the firmware.

HEVC: MT8189 is pure single core, but the firmware capability makes the
driver advertise HEVC_SLICE (and AV1). The HEVC backend only implements
the LAT + core flow, and setting an HEVC format (here libva-v4l2-request
probing its profiles when ffmpeg opened the VA-API device) sends an
init message that crashes the SCP:

  mtk-scp 1c400000.scp: SCP watchdog timeout! 0x0
  remoteproc remoteproc0: crash detected in scp: type watchdog
  scp ipi 14 ack time out !
   scp_ipi_send+0x2ec/0xd5c [mtk_scp_ipi]
   vpu_dec_init+0xe0/0x29c [mtk_vcodec_dec]
   vdec_hevc_slice_init+0x88/0x250 [mtk_vcodec_dec]
   vidioc_vdec_s_fmt+0x2a8/0x450 [mtk_vcodec_dec]

Not advertising HEVC and AV1 on MTK_VDEC_PURE_SINGLE_CORE (clearing
MTK_VDEC_FORMAT_HEVC_FRAME and MTK_VDEC_FORMAT_AV1_FRAME from
dec_capability after reading it from the firmware) avoids it; that's
what I run.

H.264 encode (patches 9 and 10 on MT8196 encoder v8): works. A 720p30
test pattern at 4 Mbit/s through ffmpeg's h264_v4l2m2m gives valid High
profile H.264, 60/60 frames, about 49 dB PSNR against the source on the
first frames.

For patches 9 and 10:
Tested-by: zoan37 <agentzoan at gmail.com>

Two board-side notes from bringing this up, in case they help whoever
writes the MT8189 DT and multimedia clocks: the VDE0 power domain needed
the larb4 gate as a subsys clock ("vdec-0", as in ChromeOS's
mt8189.dtsi), otherwise only the first decode after VDE0 powered up
worked; and the VEN1 clock controller must not use runtime PM (VEN0
then failed to prepare its subsys clock with -EACCES in the noirq resume
phase, genpd marked it on anyway, and every resume warned about
"already disabled" clocks).

The board's patches and notes are at
https://github.com/zoan37/lenovo-slim3-chromebook-omarchy

The testing and the fixes were done with help from an AI assistant
(Claude).

Thanks,
zoan37