drivers/media/platform/qcom/iris/Makefile | 1 + drivers/media/platform/qcom/iris/iris_firmware.c | 23 +- .../platform/qcom/iris/iris_platform_common.h | 11 +- .../media/platform/qcom/iris/iris_platform_gen2.c | 33 +- .../platform/qcom/iris/iris_platform_sm8250.c | 21 +- drivers/media/platform/qcom/iris/iris_power.c | 2 +- drivers/media/platform/qcom/iris/iris_probe.c | 20 +- drivers/media/platform/qcom/iris/iris_resources.c | 16 +- drivers/media/platform/qcom/iris/iris_resources.h | 1 + drivers/media/platform/qcom/iris/iris_vpu3x.c | 199 +----------- drivers/media/platform/qcom/iris/iris_vpu4x.c | 358 +++++++++++++++++++++ drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 342 ++++++++++++++++++++ drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 24 ++ drivers/media/platform/qcom/iris/iris_vpu_common.c | 188 ++++++++--- drivers/media/platform/qcom/iris/iris_vpu_common.h | 5 + .../platform/qcom/iris/iris_vpu_register_defines.h | 61 ++++ 16 files changed, 1026 insertions(+), 279 deletions(-)
Upcoming Qualcomm kaanapali platform have a newer generation of video
IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number
of power domains as well as multiple clock sources. It has support for
new codec(apv), when compared to prior generation.
From previous version of this series, the kaanapali binding patch(#1/8)
and the compatible patch(#8/8) have been dropped. The discussion for
this is captured here [1].
The series introducs buffer calculation and power sequence for vpu4. It
prepares for vpu4 when kaanapali is enabled after the binding discussion
is concluded.
[1]
https://lore.kernel.org/linux-media/fdf4c469-d276-4f64-b13d-5266cca7235c@oss.qualcomm.com/
Please review and share your comments.
Following are the compliance and functional validation reports executed
on kaanapali(vpu4). For the series to be functional on vpu4, patch #8
from version of the series need to be explicitly included.
v4l2-compliance report, for decoder followed by encoder, including
streaming tests:
v4l2-compliance 1.31.0-5396, 64 bits, 64-bit time_t
v4l2-compliance SHA: 3f22c6fcee75 2025-09-18 09:49:23
Compliance test for iris_driver device /dev/video0:
Driver Info:
Driver name : iris_driver
Card type : Iris Decoder
Bus info : platform:2000000.video-codec
Driver version : 6.17.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected Stateful Decoder
Required ioctls:
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 10 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
[ 328.905995] qcom-iris 2000000.video-codec: invalid plane
[ 332.917543] qcom-iris 2000000.video-codec: invalid plane
test blocking wait: OK
Test input 0:
Streaming ioctls:
test read/write: OK (Not Supported)
Video Capture Multiplanar: Captured 21481 buffers
[ 350.438406] qcom-iris 2000000.video-codec: invalid plane
[ 350.447079] qcom-iris 2000000.video-codec: invalid plane
[ 350.458821] qcom-iris 2000000.video-codec: invalid plane
[ 350.465860] qcom-iris 2000000.video-codec: invalid plane
test MMAP (select, REQBUFS): OK
Video Capture Multiplanar: Captured 21481 buffers
[ 363.878157] qcom-iris 2000000.video-codec: invalid plane
[ 363.886546] qcom-iris 2000000.video-codec: invalid plane
[ 363.898475] qcom-iris 2000000.video-codec: invalid plane
[ 363.905527] qcom-iris 2000000.video-codec: invalid plane
test MMAP (epoll, REQBUFS): OK
Video Capture Multiplanar: Captured 21481 buffers
[ 377.209312] qcom-iris 2000000.video-codec: invalid plane
[ 377.218027] qcom-iris 2000000.video-codec: invalid plane
[ 377.233635] qcom-iris 2000000.video-codec: invalid plane
[ 377.241360] qcom-iris 2000000.video-codec: invalid plane
test MMAP (select, CREATE_BUFS): OK
Video Capture Multiplanar: Captured 21481 buffers
[ 390.624700] qcom-iris 2000000.video-codec: invalid plane
[ 390.633590] qcom-iris 2000000.video-codec: invalid plane
[ 390.645629] qcom-iris 2000000.video-codec: invalid plane
[ 390.652618] qcom-iris 2000000.video-codec: invalid plane
test MMAP (epoll, CREATE_BUFS): OK
test USERPTR (select): OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total for iris_driver device /dev/video0: 54, Succeeded: 54, Failed: 0,
Warnings: 0
Compliance test for iris_driver device /dev/video1:
Driver Info:
Driver name : iris_driver
Card type : Iris Encoder
Bus info : platform:2000000.video-codec
Driver version : 6.17.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected Stateful Encoder
Required ioctls:
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video1 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 38 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
test blocking wait: OK
Test input 0:
Streaming ioctls:
test read/write: OK (Not Supported)
Video Capture Multiplanar: Captured 61 buffers
test MMAP (select, REQBUFS): OK
Video Capture Multiplanar: Captured 61 buffers
test MMAP (epoll, REQBUFS): OK
Video Capture Multiplanar: Captured 61 buffers
test MMAP (select, CREATE_BUFS): OK
Video Capture Multiplanar: Captured 61 buffers
test MMAP (epoll, CREATE_BUFS): OK
test USERPTR (select): OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total for iris_driver device /dev/video1: 54, Succeeded: 54, Failed: 0,
Warnings: 0
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>
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>
gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
capture-io-mode=4 output-io-mode=4 ! filesink sync=true
location=<output_file.hevc>
ffmpeg test:
Decoders validated with below commands:
ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0
output_file.yuv -y
v4l2-ctl test
Decoders validated with below commands:
v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=<input_file.h264> --stream-to=<output_file.yuv>
v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=input_file.bit --stream-to=<output_file.yuv>
v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from-hdr=input_file.hdr --stream-mmap
--stream-to=<output_file.yuv>
Encoders validated with below commands:
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d
/dev/video1
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d
/dev/video1
Note: there is a crash observed while performing below sequence
rmmod qcom-iris
modprobe qcom-iris
The crash is not seen if ".skip_retention_level = true" is added to
mmcx and mmcx_ao power domains in rpmhpd.c. This is under debug with
rpmh module owner to conclude if it to be fixed differently.
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Changes in v3:
- Drop the binding and compat patch.
- Address comments related to variable handlings (Bryan)
- Pick the updates from Dmitry related to sort register #defines and
connecting register and their corresponding bits operation (Dmitry)
- Link to v2: https://lore.kernel.org/r/20251017-knp_video-v2-0-f568ce1a4be3@oss.qualcomm.com
Changes in v2:
- Dropped dependencies from binding (Dmitry).
- Dropped optional items from binding (Dmitry, Krzysztof, Konrad).
- Updated binding in sorted order and proper alignment (Krzysztof).
- Fixed order of newly introduced kaanapali struct (Dmitry, Bryan)
- Improved readability of buffer size calculation (Bryan)
- Optimized fuse register read (Konrad).
- Fixed order of vpu register defines (Dmitry).
- Addressed few other log and commit related comments (Bryan)
- Link to v1: https://lore.kernel.org/r/20250925-knp_video-v1-0-e323c0b3c0cd@oss.qualcomm.com
---
Vikash Garodia (6):
media: iris: Add support for multiple clock sources
media: iris: Add support for multiple TZ content protection(CP) configs
media: iris: Introduce buffer size calculations for vpu4
media: iris: Move vpu register defines to common header file
media: iris: Move vpu35 specific api to common to use for vpu4
media: iris: Introduce vpu ops for vpu4 with necessary hooks
drivers/media/platform/qcom/iris/Makefile | 1 +
drivers/media/platform/qcom/iris/iris_firmware.c | 23 +-
.../platform/qcom/iris/iris_platform_common.h | 11 +-
.../media/platform/qcom/iris/iris_platform_gen2.c | 33 +-
.../platform/qcom/iris/iris_platform_sm8250.c | 21 +-
drivers/media/platform/qcom/iris/iris_power.c | 2 +-
drivers/media/platform/qcom/iris/iris_probe.c | 20 +-
drivers/media/platform/qcom/iris/iris_resources.c | 16 +-
drivers/media/platform/qcom/iris/iris_resources.h | 1 +
drivers/media/platform/qcom/iris/iris_vpu3x.c | 199 +-----------
drivers/media/platform/qcom/iris/iris_vpu4x.c | 358 +++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 342 ++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 24 ++
drivers/media/platform/qcom/iris/iris_vpu_common.c | 188 ++++++++---
drivers/media/platform/qcom/iris/iris_vpu_common.h | 5 +
.../platform/qcom/iris/iris_vpu_register_defines.h | 61 ++++
16 files changed, 1026 insertions(+), 279 deletions(-)
---
base-commit: f215d17ddbe8502804ae65d8f855100daf347061
change-id: 20250924-knp_video-aaf4c40be747
Best regards,
--
Vikash Garodia <vikash.garodia@oss.qualcomm.com>
On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote: > Upcoming Qualcomm kaanapali platform have a newer generation of video > IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number > of power domains as well as multiple clock sources. It has support for > new codec(apv), when compared to prior generation. > > From previous version of this series, the kaanapali binding patch(#1/8) > and the compatible patch(#8/8) have been dropped. The discussion for > this is captured here [1]. > The series introducs buffer calculation and power sequence for vpu4. It > prepares for vpu4 when kaanapali is enabled after the binding discussion > is concluded. > > > gstreamer test: > Decoders validated with below commands, codec specific: Why not just run the fluster testsuite? > 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> > > 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> > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc > capture-io-mode=4 output-io-mode=4 ! filesink sync=true > location=<output_file.hevc> > > ffmpeg test: > Decoders validated with below commands: > ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0 > output_file.yuv -y > ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0 > output_file.yuv -y > ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0 > output_file.yuv -y > > v4l2-ctl test > Decoders validated with below commands: > v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264 > --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap > --stream-from=<input_file.h264> --stream-to=<output_file.yuv> > > v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC > --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap > --stream-from=input_file.bit --stream-to=<output_file.yuv> > > v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90 > --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap > --stream-from-hdr=input_file.hdr --stream-mmap > --stream-to=<output_file.yuv> > > Encoders validated with below commands: > v4l2-ctl --verbose > --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12 > --set-selection-output > target=crop,top=0,left=0,width=<width>,height=<height> > --set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap > --stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d > /dev/video1 > v4l2-ctl --verbose > --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12 > --set-selection-output > target=crop,top=0,left=0,width=<width>,height=<height> > --set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap > --stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d > /dev/video1 > > Note: there is a crash observed while performing below sequence > rmmod qcom-iris > modprobe qcom-iris > The crash is not seen if ".skip_retention_level = true" is added to > mmcx and mmcx_ao power domains in rpmhpd.c. This is under debug with > rpmh module owner to conclude if it to be fixed differently. > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> > --- > Changes in v3: > - Drop the binding and compat patch. > - Address comments related to variable handlings (Bryan) > - Pick the updates from Dmitry related to sort register #defines and > connecting register and their corresponding bits operation (Dmitry) > - Link to v2: https://lore.kernel.org/r/20251017-knp_video-v2-0-f568ce1a4be3@oss.qualcomm.com > > Changes in v2: > - Dropped dependencies from binding (Dmitry). > - Dropped optional items from binding (Dmitry, Krzysztof, Konrad). > - Updated binding in sorted order and proper alignment (Krzysztof). > - Fixed order of newly introduced kaanapali struct (Dmitry, Bryan) > - Improved readability of buffer size calculation (Bryan) > - Optimized fuse register read (Konrad). > - Fixed order of vpu register defines (Dmitry). > - Addressed few other log and commit related comments (Bryan) > - Link to v1: https://lore.kernel.org/r/20250925-knp_video-v1-0-e323c0b3c0cd@oss.qualcomm.com > > --- > Vikash Garodia (6): > media: iris: Add support for multiple clock sources > media: iris: Add support for multiple TZ content protection(CP) configs > media: iris: Introduce buffer size calculations for vpu4 > media: iris: Move vpu register defines to common header file > media: iris: Move vpu35 specific api to common to use for vpu4 > media: iris: Introduce vpu ops for vpu4 with necessary hooks > > drivers/media/platform/qcom/iris/Makefile | 1 + > drivers/media/platform/qcom/iris/iris_firmware.c | 23 +- > .../platform/qcom/iris/iris_platform_common.h | 11 +- > .../media/platform/qcom/iris/iris_platform_gen2.c | 33 +- > .../platform/qcom/iris/iris_platform_sm8250.c | 21 +- > drivers/media/platform/qcom/iris/iris_power.c | 2 +- > drivers/media/platform/qcom/iris/iris_probe.c | 20 +- > drivers/media/platform/qcom/iris/iris_resources.c | 16 +- > drivers/media/platform/qcom/iris/iris_resources.h | 1 + > drivers/media/platform/qcom/iris/iris_vpu3x.c | 199 +----------- > drivers/media/platform/qcom/iris/iris_vpu4x.c | 358 +++++++++++++++++++++ > drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 342 ++++++++++++++++++++ > drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 24 ++ > drivers/media/platform/qcom/iris/iris_vpu_common.c | 188 ++++++++--- > drivers/media/platform/qcom/iris/iris_vpu_common.h | 5 + > .../platform/qcom/iris/iris_vpu_register_defines.h | 61 ++++ > 16 files changed, 1026 insertions(+), 279 deletions(-) > --- > base-commit: f215d17ddbe8502804ae65d8f855100daf347061 > change-id: 20250924-knp_video-aaf4c40be747 > > Best regards, > -- > Vikash Garodia <vikash.garodia@oss.qualcomm.com> > -- With best wishes Dmitry
On 11/11/2025 4:08 PM, Dmitry Baryshkov wrote: > On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote: >> Upcoming Qualcomm kaanapali platform have a newer generation of video >> IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number >> of power domains as well as multiple clock sources. It has support for >> new codec(apv), when compared to prior generation. >> >> From previous version of this series, the kaanapali binding patch(#1/8) >> and the compatible patch(#8/8) have been dropped. The discussion for >> this is captured here [1]. >> The series introducs buffer calculation and power sequence for vpu4. It >> prepares for vpu4 when kaanapali is enabled after the binding discussion >> is concluded. >> >> >> gstreamer test: >> Decoders validated with below commands, codec specific: > Why not just run the fluster testsuite? > yeah, fluster can also be executed. Individual codec commands were explicitly called out incase someone wants to run standalone gst pipeline. >> 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> >> >> 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> >> >> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse >> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc >> capture-io-mode=4 output-io-mode=4 ! filesink sync=true >> location=<output_file.hevc> Regards, Vikash
On Tue, 11 Nov 2025 at 14:43, Vikash Garodia <vikash.garodia@oss.qualcomm.com> wrote: > > > On 11/11/2025 4:08 PM, Dmitry Baryshkov wrote: > > On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote: > >> Upcoming Qualcomm kaanapali platform have a newer generation of video > >> IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number > >> of power domains as well as multiple clock sources. It has support for > >> new codec(apv), when compared to prior generation. > >> > >> From previous version of this series, the kaanapali binding patch(#1/8) > >> and the compatible patch(#8/8) have been dropped. The discussion for > >> this is captured here [1]. > >> The series introducs buffer calculation and power sequence for vpu4. It > >> prepares for vpu4 when kaanapali is enabled after the binding discussion > >> is concluded. > >> > >> > >> gstreamer test: > >> Decoders validated with below commands, codec specific: > > Why not just run the fluster testsuite? > > > > yeah, fluster can also be executed. Individual codec commands were > explicitly called out incase someone wants to run standalone gst pipeline. Please switch to fluster (in addition to Gst), ideally running all test cases for a codec. While enabling SC7280 support I found that there are enough corner cases which are being ignored by the driver. One additional bonus is that fluster runs several process in parallel by default, catching issues caused by several decode threads running in parallel. > > >> 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> > >> > >> 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> > >> > >> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse > >> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc > >> capture-io-mode=4 output-io-mode=4 ! filesink sync=true > >> location=<output_file.hevc> > > Regards, > Vikash -- With best wishes Dmitry
On 11/11/2025 7:09 PM, Dmitry Baryshkov wrote: > On Tue, 11 Nov 2025 at 14:43, Vikash Garodia > <vikash.garodia@oss.qualcomm.com> wrote: >> >> >> On 11/11/2025 4:08 PM, Dmitry Baryshkov wrote: >>> On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote: >>>> Upcoming Qualcomm kaanapali platform have a newer generation of video >>>> IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number >>>> of power domains as well as multiple clock sources. It has support for >>>> new codec(apv), when compared to prior generation. >>>> >>>> From previous version of this series, the kaanapali binding patch(#1/8) >>>> and the compatible patch(#8/8) have been dropped. The discussion for >>>> this is captured here [1]. >>>> The series introducs buffer calculation and power sequence for vpu4. It >>>> prepares for vpu4 when kaanapali is enabled after the binding discussion >>>> is concluded. >>>> >>>> >>>> gstreamer test: >>>> Decoders validated with below commands, codec specific: >>> Why not just run the fluster testsuite? >>> >> >> yeah, fluster can also be executed. Individual codec commands were >> explicitly called out incase someone wants to run standalone gst pipeline. > > Please switch to fluster (in addition to Gst), ideally running all > test cases for a codec. While enabling SC7280 support I found that > there are enough corner cases which are being ignored by the driver. > One additional bonus is that fluster runs several process in parallel > by default, catching issues caused by several decode threads running > in parallel. > multi process issue is due to below [1] (tried it on lemans). Due to higher concurrency, we can see that the DMA buffer is mapped into un-addressable range (0-0x25800000) i.e 0x24b00000, and leading to global fault. This was the reason i was keeping 2 memory-region in kaanapali binding, to restrict certain ranges of IOVA. Below solutions are being tried, again this is not limited to kaanapali and applies to existing enabled SOCs as well. 1. introduce dynamic device for output buffers which are big size comparatively, via iommu-map 2. introduce the restrictions to the addressable range. [1] 157.511807: SMMU_ERR_FATAL_NSEC_FAULT_NAME_REG : SMMU:>> 0x0x15000000 NonSec Global Fault: NSGFSR=0x80000002, NSGFAR1=0x00000000, NSGFAR0=0x24b00000, NSGFSYNR0=0x00000004, NSGFSYNR1=0x08840884, NSGFSYNR2=0x00000000, NSCR0=0x00280406 >> >>>> 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> >>>> >>>> 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> >>>> >>>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse >>>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc >>>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true >>>> location=<output_file.hevc> >> >> Regards, >> Vikash > > >
On 12/11/2025 05:09, Vikash Garodia wrote: >> One additional bonus is that fluster runs several process in parallel >> by default, catching issues caused by several decode threads running >> in parallel. >> > multi process issue is due to below [1] (tried it on lemans). Due to > higher concurrency, we can see that the DMA buffer is mapped into > un-addressable range (0-0x25800000) i.e 0x24b00000, and leading to > global fault. This was the reason i was keeping 2 memory-region in > kaanapali binding, to restrict certain ranges of IOVA. If that is currently true then we should restrict concurrent sessions entirely unless/until it can be safely supported. --- bod
On 11/20/2025 3:19 PM, Bryan O'Donoghue wrote: > On 12/11/2025 05:09, Vikash Garodia wrote: >>> One additional bonus is that fluster runs several process in parallel >>> by default, catching issues caused by several decode threads running >>> in parallel. >>> >> multi process issue is due to below [1] (tried it on lemans). Due to >> higher concurrency, we can see that the DMA buffer is mapped into >> un-addressable range (0-0x25800000) i.e 0x24b00000, and leading to >> global fault. This was the reason i was keeping 2 memory-region in >> kaanapali binding, to restrict certain ranges of IOVA. > > If that is currently true then we should restrict concurrent sessions > entirely unless/until it can be safely supported. > I would prefer to fix it than disable the feature. I would raising a fix for it. Also, to keep it clear, this is nothing to do with this patch series. The issue about non usable IOVA range has been there for qcom vpu, it not newly introduced in iris driver. It was not exposed in venus and it is seen now in iris with concurrency when IOVA falls into that non addressable range. Regards, Vikash
On Wed, Nov 12, 2025 at 10:39:16AM +0530, Vikash Garodia wrote: > > On 11/11/2025 7:09 PM, Dmitry Baryshkov wrote: > > On Tue, 11 Nov 2025 at 14:43, Vikash Garodia > > <vikash.garodia@oss.qualcomm.com> wrote: > > > > > > > > > On 11/11/2025 4:08 PM, Dmitry Baryshkov wrote: > > > > On Fri, Nov 07, 2025 at 03:19:35PM +0530, Vikash Garodia wrote: > > > > > Upcoming Qualcomm kaanapali platform have a newer generation of video > > > > > IP, iris4 or vpu4. The hardware have evolved mostly w.r.t higher number > > > > > of power domains as well as multiple clock sources. It has support for > > > > > new codec(apv), when compared to prior generation. > > > > > > > > > > From previous version of this series, the kaanapali binding patch(#1/8) > > > > > and the compatible patch(#8/8) have been dropped. The discussion for > > > > > this is captured here [1]. > > > > > The series introducs buffer calculation and power sequence for vpu4. It > > > > > prepares for vpu4 when kaanapali is enabled after the binding discussion > > > > > is concluded. > > > > > > > > > > > > > > > gstreamer test: > > > > > Decoders validated with below commands, codec specific: > > > > Why not just run the fluster testsuite? > > > > > > > > > > yeah, fluster can also be executed. Individual codec commands were > > > explicitly called out incase someone wants to run standalone gst pipeline. > > > > Please switch to fluster (in addition to Gst), ideally running all > > test cases for a codec. While enabling SC7280 support I found that > > there are enough corner cases which are being ignored by the driver. > > One additional bonus is that fluster runs several process in parallel > > by default, catching issues caused by several decode threads running > > in parallel. > > > > multi process issue is due to below [1] (tried it on lemans). Due to higher I haven't seen SMMU errors on Kodiak. > concurrency, we can see that the DMA buffer is mapped into un-addressable > range (0-0x25800000) i.e 0x24b00000, and leading to global fault. This was > the reason i was keeping 2 memory-region in kaanapali binding, to restrict > certain ranges of IOVA. > > Below solutions are being tried, again this is not limited to kaanapali and > applies to existing enabled SOCs as well. > > 1. introduce dynamic device for output buffers which are big size > comparatively, via iommu-map > 2. introduce the restrictions to the addressable range. Hoping to see them posted and land soon. > > [1] > 157.511807: SMMU_ERR_FATAL_NSEC_FAULT_NAME_REG : SMMU:>> 0x0x15000000 > NonSec Global Fault: NSGFSR=0x80000002, NSGFAR1=0x00000000, > NSGFAR0=0x24b00000, NSGFSYNR0=0x00000004, NSGFSYNR1=0x08840884, > NSGFSYNR2=0x00000000, NSCR0=0x00280406 > > > > > > > > > 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> > > > > > > > > > > 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> > > > > > > > > > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse > > > > > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc > > > > > capture-io-mode=4 output-io-mode=4 ! filesink sync=true > > > > > location=<output_file.hevc> > > > > > > Regards, > > > Vikash > > > > > > > -- With best wishes Dmitry
© 2016 - 2025 Red Hat, Inc.