Re: [PATCH 0/7] media: iris: add support for kaanapali platform

From: Vikash Garodia

Date: Tue Jan 27 2026 - 06:27:00 EST



On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
Qualcomm kaanapali platform have a newer generation of video IP iris4.
The hardware have evolved mostly with respect to higher number of power
domains as well as multiple clock sources.

The series extends support for multiple iommu-map entries for the same
input id. Considering iris as a client driver, it adds the handling for
multiple stream ids from VPU via iommu-map.

This series is depend on the below series:
Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@xxxxxxxxxxxxxxxx/

Following are the compliance and functional validation reports.

Please validate with fluster too. Having a "knowingly good" command line
is not a validation. It can't be reproduced by anybody else.


Below is the fluster result on kaanapali (will add in cover letter in next revision)

H264:
77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
- 52 test vectors failed due to interlaced clips - not supported
- 3 test vectors failed due to unsupported bitstream.
- 2 test vectors failed because SP_SLICE type - not supported by the
hardware.
- 1 test vector failed due to unsupported profile

H265:
129/147 testcases passed while testing JCT-VC-HEVC_V1 with
GStreamer-H.265-V4L2-Gst1.0.
The failing test case:
- 10 testcases failed due to unsupported 10 bit format.
- 4 testcase failed due to unsupported resolution
- 2 testcase failed due to CRC mismatch
- 2 test fails due to session error (under debug)
- PICSIZE_C_Bossen_1
- WPP_E_ericsson_MAIN_2

VP9:
235/305 testcases passed while testing VP9-TEST-VECTORS with
GStreamer-VP9-V4L2-Gst1.0.
The failing test case:
- 64 testcases failed due to unsupported resolution
- 2 testcases failed due to unsupported format
- 1 testcase failed with CRC mismatch (fails with ref decoder as well)
- 2 testcase failed due to unsupported resolution after sequence change
- 1 testcase failed due to unsupported stream

gstreamer test:
Decoders validated with below commands, codec specific:
gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

Neither of these commands specify, what exactly was validated. They
specify that you've validated _some_ videos. It's impossible to even
reproduce your results, because you don't specify which files you've
used.


commands are shared indicating the pipeline used for validation for different codec plugins. These are some basic encode and decode commands, and shared for reference for anyone to pick input test files of their own.


gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

Encoders validated with below commands:
gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
capture-io-mode=4 output-io-mode=4 ! filesink sync=true
location=<output_file.h264>

At least these should use test sinks in order to be reproducible.

it is using filesink in the pipeline to generate the encoded bitstream

Regards,
Vikash