* [PATCH v4 0/3] media: qcom: Add support for the iris codec on shikra
@ 2026-07-21 17:32 Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Vikash Garodia @ 2026-07-21 17:32 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy, Konrad Dybcio, Dmitry Baryshkov
The shikra platform uses AR50_LITE IP core as video en/decoder codec
block (the same as agatti platform). Extend iris driver to support this
platform. This has been tested on the Qualcomm shikra boards, shikra-cqm-evk,
shikra-cqs-evk and shikra-iqs-evk boards with HFI Gen2 firmware.
v4l2-compliance results:
v4l2-compliance -d /dev/video1 -s
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/video1:
Driver Info:
Driver name : iris_driver
Card type : Iris Encoder
Bus info : platform:5a00000.video-codec
Driver version : 7.0.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: 41 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
v4l2-compliance -d /dev/video0 -s5
--stream-from=./data/resource/simple_AVC_720p_10fps_90frames.264
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:5a00000.video-codec
Driver version : 7.0.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)
test blocking wait: OK
Test input 0:
Streaming ioctls:
test read/write: OK (Not Supported)
the input file is smaller than 7077888 bytes
Video Capture Multiplanar: Captured 65 buffers
test MMAP (select, REQBUFS): OK
the input file is smaller than 7077888 bytes
Video Capture Multiplanar: Captured 65 buffers
test MMAP (epoll, REQBUFS): OK
the input file is smaller than 7077888 bytes
Video Capture Multiplanar: Captured 65 buffers
test MMAP (select, CREATE_BUFS): OK
the input file is smaller than 7077888 bytes
Video Capture Multiplanar: Captured 65 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/video0: 54, Succeeded: 54, Failed: 0,
Warnings: 0
Fluster results for HFI Gen2 firmware:
./fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-V4L2-Gst1.0 - 77/135
The failing test case:
- Unsupported profile: H.264 Extended profile is deprecated.
- BA3_SVA_C
- Interlaced content is not supported yet.
- CABREF3_Sand_D
- CAFI1_SVA_C
- CAMA1_Sony_C
- CAMA1_TOSHIBA_B
- CAMA3_Sand_E
- CAMACI3_Sony_C
- CAMANL1_TOSHIBA_B
- CAMANL2_TOSHIBA_B
- CAMANL3_Sand_E
- CAMASL3_Sony_B
- CAMP_MOT_MBAFF_L30
- CAMP_MOT_MBAFF_L31
- CANLMA2_Sony_C
- CANLMA3_Sony_C
- CAPA1_TOSHIBA_B
- CAPAMA3_Sand_F
- CVCANLMA2_Sony_C
- CVFI1_SVA_C
- CVFI1_Sony_D
- CVFI2_SVA_C
- CVFI2_Sony_H
- CVMA1_Sony_D
- CVMA1_TOSHIBA_B
- CVMANL1_TOSHIBA_B
- CVMANL2_TOSHIBA_B
- CVMAPAQP3_Sony_E
- CVMAQP2_Sony_G
- CVMAQP3_Sony_D
- CVMP_MOT_FLD_L30_B
- CVMP_MOT_FRM_L31
- CVNLFI1_Sony_C
- CVNLFI2_Sony_H
- CVPA1_TOSHIBA_B
- FI1_Sony_E
- MR6_BT_B
- MR7_BT_B
- MR8_BT_B
- MR9_BT_B
- Sharp_MP_Field_1_B
- Sharp_MP_Field_2_B
- Sharp_MP_Field_3_B
- Sharp_MP_PAFF_1r2
- Sharp_MP_PAFF_2r
- cabac_mot_fld0_full
- cabac_mot_mbaff0_full
- cabac_mot_picaff0_full
- cama1_vtc_c
- cama2_vtc_b
- cama3_vtc_b
- cavlc_mot_fld0_full_B
- cavlc_mot_mbaff0_full_B
- cavlc_mot_picaff0_full_B
- Unsupported bitstream: num_slice_group_minus1 > 0 (slice groups not
supported by hardware).
- FM1_BT_B
- FM1_FT_E
- FM2_SVA_C
- Unsupported bitstream: SP slice type is not supported by hardware.
- SP1_BT_A
- sp2_bt_b
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2-Gst1.0 -
113/147
The failing test case:
- Unsupported level
- AMP_D_Hisilicon_3
- AMP_E_Hisilicon_3
- AMP_F_Hisilicon_3
- DELTAQP_A_BRCM_4
- IPRED_A_docomo_2
- IPRED_C_Mitsubishi_3
- LS_A_Orange_2
- LS_B_Orange_4
- PPS_A_qualcomm_7
- RAP_B_Bossen_2
- RPS_F_docomo_2
- SAO_G_Canon_3
- SDH_A_Orange_4
- 10bit content - not supported in this generation of video IP
- DBLK_A_MAIN10_VIXS_4
- INITQP_B_Main10_Sony_1
- TSUNEQBD_A_MAIN10_Technicolor_2
- WPP_A_ericsson_MAIN10_2
- WPP_B_ericsson_MAIN10_2
- WPP_C_ericsson_MAIN10_2
- WPP_D_ericsson_MAIN10_2
- WPP_E_ericsson_MAIN10_2
- WPP_F_ericsson_MAIN10_2
- WP_A_MAIN10_Toshiba_3
- WP_MAIN10_B_Toshiba_3
- Unsupported resolution
- AMP_A_Samsung_7
- AMP_B_Samsung_7
- PICSIZE_A_Bossen_1
- PICSIZE_B_Bossen_1
- PICSIZE_C_Bossen_1
- PICSIZE_D_Bossen_1
- TUSIZE_A_Samsung_1
- WPP_D_ericsson_MAIN_2
- CRC mismatch
- RAP_A_docomo_6
- CRC mismatch - bitstream issue - fails with ffmpeg sw decoder as well
- VPSSPSPPS_A_MainConcept_1
./fluster.py run -ts VP9-TEST-VECTORS -d GStreamer-VP9-V4L2-Gst1.0 -j1 - 206/305
The failing test case:
- Unsupported resolution
- vp90-2-02-size-08x08.webm
- vp90-2-02-size-08x10.webm
- vp90-2-02-size-08x16.webm
- vp90-2-02-size-08x18.webm
- vp90-2-02-size-08x32.webm
- vp90-2-02-size-08x34.webm
- vp90-2-02-size-08x64.webm
- vp90-2-02-size-08x66.webm
- vp90-2-02-size-10x08.webm
- vp90-2-02-size-10x10.webm
- vp90-2-02-size-10x16.webm
- vp90-2-02-size-10x18.webm
- vp90-2-02-size-10x32.webm
- vp90-2-02-size-10x34.webm
- vp90-2-02-size-10x64.webm
- vp90-2-02-size-10x66.webm
- vp90-2-02-size-16x08.webm
- vp90-2-02-size-16x10.webm
- vp90-2-02-size-16x16.webm
- vp90-2-02-size-16x18.webm
- vp90-2-02-size-16x32.webm
- vp90-2-02-size-16x34.webm
- vp90-2-02-size-16x64.webm
- vp90-2-02-size-16x66.webm
- vp90-2-02-size-18x08.webm
- vp90-2-02-size-18x10.webm
- vp90-2-02-size-18x16.webm
- vp90-2-02-size-18x18.webm
- vp90-2-02-size-18x32.webm
- vp90-2-02-size-18x34.webm
- vp90-2-02-size-18x64.webm
- vp90-2-02-size-18x66.webm
- vp90-2-02-size-32x08.webm
- vp90-2-02-size-32x10.webm
- vp90-2-02-size-32x16.webm
- vp90-2-02-size-32x18.webm
- vp90-2-02-size-32x32.webm
- vp90-2-02-size-32x34.webm
- vp90-2-02-size-32x64.webm
- vp90-2-02-size-32x66.webm
- vp90-2-02-size-34x08.webm
- vp90-2-02-size-34x10.webm
- vp90-2-02-size-34x16.webm
- vp90-2-02-size-34x18.webm
- vp90-2-02-size-34x32.webm
- vp90-2-02-size-34x34.webm
- vp90-2-02-size-34x64.webm
- vp90-2-02-size-34x66.webm
- vp90-2-02-size-64x08.webm
- vp90-2-02-size-64x10.webm
- vp90-2-02-size-64x16.webm
- vp90-2-02-size-64x18.webm
- vp90-2-02-size-64x32.webm
- vp90-2-02-size-64x34.webm
- vp90-2-02-size-64x64.webm
- vp90-2-02-size-64x66.webm
- vp90-2-02-size-66x08.webm
- vp90-2-02-size-66x10.webm
- vp90-2-02-size-66x16.webm
- vp90-2-02-size-66x18.webm
- vp90-2-02-size-66x32.webm
- vp90-2-02-size-66x34.webm
- vp90-2-02-size-66x64.webm
- vp90-2-02-size-66x66.webm
- vp90-2-08-tile_1x8.webm
- vp90-2-08-tile_1x8_frame_parallel.webm
- vp90-2-14-resize-10frames-fp-tiles-1-2-4-8.webm
- vp90-2-14-resize-10frames-fp-tiles-1-8.webm
- vp90-2-14-resize-10frames-fp-tiles-2-8.webm
- vp90-2-14-resize-10frames-fp-tiles-4-8.webm
- vp90-2-14-resize-10frames-fp-tiles-8-1.webm
- vp90-2-14-resize-10frames-fp-tiles-8-2.webm
- vp90-2-14-resize-10frames-fp-tiles-8-4-2-1.webm
- vp90-2-14-resize-10frames-fp-tiles-8-4.webm
- vp90-2-14-resize-fp-tiles-1-16.webm
- vp90-2-14-resize-fp-tiles-1-2-4-8-16.webm
- vp90-2-14-resize-fp-tiles-1-8.webm
- vp90-2-14-resize-fp-tiles-16-1.webm
- vp90-2-14-resize-fp-tiles-16-2.webm
- vp90-2-14-resize-fp-tiles-16-4.webm
- vp90-2-14-resize-fp-tiles-16-8-4-2-1.webm
- vp90-2-14-resize-fp-tiles-16-8.webm
- vp90-2-14-resize-fp-tiles-2-16.webm
- vp90-2-14-resize-fp-tiles-2-8.webm
- vp90-2-14-resize-fp-tiles-4-16.webm
- vp90-2-14-resize-fp-tiles-4-8.webm
- vp90-2-14-resize-fp-tiles-8-1.webm
- vp90-2-14-resize-fp-tiles-8-16.webm
- vp90-2-14-resize-fp-tiles-8-2.webm
- vp90-2-14-resize-fp-tiles-8-4.webm
- Unsupported format
- vp91-2-04-yuv422.webm
- vp91-2-04-yuv444.webm
- CRC mismatch
- vp90-2-22-svc_1280x720_3.ivf
- Unsupported resolution after sequence change
- vp90-2-18-resize.ivf
- vp90-2-21-resize_inter_320x180_5_1-2.webm
- vp90-2-21-resize_inter_320x180_7_1-2.webm
- vp90-2-21-resize_inter_320x240_5_1-2.webm
- p90-2-21-resize_inter_320x240_7_1-2.webm
- Unsupported stream
- vp90-2-16-intra-only.webm
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Changes in v4:
- Added handling for 600MB (Bryan)
- Link to v3: https://lore.kernel.org/r/20260618-shikra_vpu-v3-0-1a32e26a35a1@oss.qualcomm.com
Changes in v3:
- Fix the compat name (Bryan, Dmitry)
- Link to v2: https://lore.kernel.org/r/20260612-shikra_vpu-v2-0-bf8727370a1e@oss.qualcomm.com
Changes in v2:
- Move the if/then schema at the end (Krzysztof)
- Fixed the order of compat (Krzysztof)
- Link to v1: https://lore.kernel.org/r/20260609-shikra_vpu-v1-0-3a32bb38b080@oss.qualcomm.com
---
Vikash Garodia (3):
dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
arm64: dts: qcom: shikra: Add Iris video codec node
arm64: dts: qcom: shikra-evk: Enable Iris core
.../bindings/media/qcom,qcm2290-venus.yaml | 26 +++++---
.../bindings/media/qcom,venus-common.yaml | 5 +-
arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 6 ++
arch/arm64/boot/dts/qcom/shikra.dtsi | 71 ++++++++++++++++++++++
4 files changed, 100 insertions(+), 8 deletions(-)
---
base-commit: 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
change-id: 20260721-shikra_vpu-f37cfc006aba
prerequisite-message-id: <20260718-shikra-dispcc-gpucc-v6-0-62703e05ef0f@oss.qualcomm.com>
prerequisite-patch-id: 6858ed1e274262616eda5e8138290025d8abda1a
prerequisite-patch-id: 23b24fb512c882a045ed8339b22269bfc2c5d02c
prerequisite-patch-id: 823bc7bc713f6fce1b9de47a266307f1829636b9
prerequisite-patch-id: b4d934b7494892e273bedcad87fd422e09932b12
prerequisite-patch-id: 2f989fe8a34276dca1c97832663c736cb7d10786
prerequisite-patch-id: e7a1bab5625cb4ae230614069399a0d0b2373350
prerequisite-patch-id: b59fd05f9b62bda86079c9d86538b80289110862
prerequisite-patch-id: 71691d8b40e36cdbff6a52c3999ea8bb2c164d70
prerequisite-patch-id: b2868bc50d74afd13c8a0d0fd62301fa9546a211
prerequisite-patch-id: f83f24719ac475317507af09bf08b4a69b02d429
prerequisite-patch-id: c9f2942207341ad4f450b20f049199f35188c02a
prerequisite-patch-id: 4d46b63b5c30f86a941f41fccc5cdc4f60383bca
prerequisite-patch-id: 0396ac157aba73a5afd7ba4a8a744847f5a7b433
prerequisite-patch-id: 2b1aecd97b9c073a1b323138cd7a98cb34e3715f
prerequisite-patch-id: 3a6e9752793f2d7b084008b47daed10ea572064a
prerequisite-patch-id: ad0c7612d91347317d038355e9e9b093169f1521
Best regards,
--
Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-21 17:32 [PATCH v4 0/3] media: qcom: Add support for the iris codec on shikra Vikash Garodia
@ 2026-07-21 17:32 ` Vikash Garodia
2026-07-22 7:15 ` Krzysztof Kozlowski
` (2 more replies)
2026-07-21 17:32 ` [PATCH v4 2/3] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 3/3] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
2 siblings, 3 replies; 11+ messages in thread
From: Vikash Garodia @ 2026-07-21 17:32 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Vishnu Reddy
Document the iris video accelerator used on shikra platforms by adding
the qcom,shikra-iris compatible.
Although QCM2290 and shikra share the same video hardware and overall
integration, their SMMU programming differs. QCM2290 exposes separate
stream IDs for the video hardware and the Xtensa path, requiring two
explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
and Xtensa isolation requirements, such SMR masking is not applicable on
QCM2290 platforms.
Since shikra uses the same video hardware as QCM2290 and shares the same
programming model and capabilities, it is added as a fallback compatible
to qcom,qcm2290-venus, with conditional handling to allow either one or
two IOMMU entries.
Common schema is updated to accommodate the iova restriction of 600MB.
VPU restricts usage of 600MB for specific streams, which could otherwise
lead to device crash.
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
.../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
.../bindings/media/qcom,venus-common.yaml | 5 ++++-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
index 5977e7d0a71b4fb5681f1c2094439c251366f01f..b27899ebf164229ceff1ca5cda50ee30d875e953 100644
--- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
@@ -13,14 +13,13 @@ description:
The Venus AR50_LITE IP is a video encode and decode accelerator present
on Qualcomm platforms.
-allOf:
- - $ref: qcom,venus-common.yaml#
-
properties:
compatible:
oneOf:
- items:
- - const: qcom,sm6115-venus
+ - enum:
+ - qcom,shikra-venus
+ - qcom,sm6115-venus
- const: qcom,qcm2290-venus
- const: qcom,qcm2290-venus
@@ -45,9 +44,6 @@ properties:
- const: vcodec0_core
- const: vcodec0_bus
- iommus:
- maxItems: 2
-
interconnects:
maxItems: 2
@@ -65,6 +61,22 @@ required:
- power-domain-names
- iommus
+allOf:
+ - $ref: qcom,venus-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,shikra-venus
+ then:
+ properties:
+ iommus:
+ maxItems: 1
+ else:
+ properties:
+ iommus:
+ maxItems: 2
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -37,7 +37,10 @@ properties:
maxItems: 20
memory-region:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Firmware-loaded codec carveout
+ - description: IOMMU IOVA reservation region
power-domains:
minItems: 1
--
2.34.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v4 2/3] arm64: dts: qcom: shikra: Add Iris video codec node
2026-07-21 17:32 [PATCH v4 0/3] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
@ 2026-07-21 17:32 ` Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 3/3] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
2 siblings, 0 replies; 11+ messages in thread
From: Vikash Garodia @ 2026-07-21 17:32 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Konrad Dybcio, Dmitry Baryshkov, Vishnu Reddy
Add the Iris video codec device tree node for the Shikra platform.
Shikra reuses the QCM2290-class video hardware and programming model.
The video node is added to describe the Iris based video decoder
encoder block, allowing the media driver to probe and initialize
the hardware.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 71 ++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 2a131ae601a7040142da16e39dbe2f8563ef43ee..8449af599cfc501bf17904c7533b0796948f8fb3 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -314,6 +314,16 @@ lmcu_dtb_mem: lmcu-dtb@b4702000 {
reg = <0x0 0xb4702000 0x0 0x40000>;
no-map;
};
+
+ /*
+ * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+ * DMA into that range triggers unhandled SMMU faults and
+ * spontaneous reboots, so reserve it to keep IOMMU
+ * allocation above this boundary.
+ */
+ iris_iova: iris-iova {
+ iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+ };
};
soc: soc@0 {
@@ -655,6 +665,67 @@ gpucc: clock-controller@5990000 {
#power-domain-cells = <1>;
};
+ iris: video-codec@5a00000 {
+ compatible = "qcom,shikra-venus", "qcom,qcm2290-venus";
+ reg = <0x0 0x05a00000 0x0 0x200000>;
+ interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ power-domains = <&gcc GCC_VENUS_GDSC>,
+ <&gcc GCC_VCODEC0_GDSC>,
+ <&rpmpd QCM2290_VDDCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "cx";
+ operating-points-v2 = <&venus_opp_table>;
+
+ clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>,
+ <&gcc GCC_VIDEO_AHB_CLK>,
+ <&gcc GCC_VENUS_CTL_AXI_CLK>,
+ <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>,
+ <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>,
+ <&gcc GCC_VCODEC0_AXI_CLK>;
+ clock-names = "core",
+ "iface",
+ "bus",
+ "throttle",
+ "vcodec0_core",
+ "vcodec0_bus";
+
+ memory-region = <&video_mem>, <&iris_iova>;
+ interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
+ <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
+ &config_noc SLAVE_VENUS_CFG RPM_ACTIVE_TAG>;
+ interconnect-names = "video-mem",
+ "cpu-cfg";
+
+ iommus = <&apps_smmu 0x780 0x20>;
+
+ venus_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133333333 {
+ opp-hz = /bits/ 64 <133333333>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmpd_opp_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ };
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ required-opps = <&rpmpd_opp_nom>;
+ };
+ };
+ };
+
dispcc: clock-controller@5f00000 {
compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
reg = <0x0 0x05f00000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v4 3/3] arm64: dts: qcom: shikra-evk: Enable Iris core
2026-07-21 17:32 [PATCH v4 0/3] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 2/3] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
@ 2026-07-21 17:32 ` Vikash Garodia
2 siblings, 0 replies; 11+ messages in thread
From: Vikash Garodia @ 2026-07-21 17:32 UTC (permalink / raw)
To: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vikash Garodia, Dmitry Baryshkov, Vishnu Reddy
Enable video en/decoder on the Shikra EVK board.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
index 6eb4184f76422d57766ba34647010c690646fdab..696df7c9a7e0f7c86955066e76df3d8fcb8bad1f 100644
--- a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
@@ -3,6 +3,12 @@
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
+&iris {
+ firmware-name = "qcom/vpu/ar50lt_p1_gen2_s6.mbn";
+
+ status = "okay";
+};
+
&qupv3_0 {
firmware-name = "qcom/shikra/qupv3fw.elf";
--
2.34.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
@ 2026-07-22 7:15 ` Krzysztof Kozlowski
2026-07-22 10:57 ` Vikash Garodia
2026-07-31 11:57 ` Dmitry Baryshkov
2026-07-31 13:39 ` Bryan O'Donoghue
2 siblings, 1 reply; 11+ messages in thread
From: Krzysztof Kozlowski @ 2026-07-22 7:15 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
> Document the iris video accelerator used on shikra platforms by adding
> the qcom,shikra-iris compatible.
iris here, venus in the compatible. Please decide which one.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
This paragraph suggests devices are not compatible. Will Shikra Iris
work fine when driver matches with qcom,qcm2290-venus?
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
> Common schema is updated to accommodate the iova restriction of 600MB.
> VPU restricts usage of 600MB for specific streams, which could otherwise
> lead to device crash.
>
> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
> .../bindings/media/qcom,venus-common.yaml | 5 ++++-
> 2 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> index 5977e7d0a71b4fb5681f1c2094439c251366f01f..b27899ebf164229ceff1ca5cda50ee30d875e953 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> @@ -13,14 +13,13 @@ description:
> The Venus AR50_LITE IP is a video encode and decode accelerator present
> on Qualcomm platforms.
>
> -allOf:
> - - $ref: qcom,venus-common.yaml#
> -
> properties:
> compatible:
> oneOf:
> - items:
> - - const: qcom,sm6115-venus
> + - enum:
> + - qcom,shikra-venus
> + - qcom,sm6115-venus
> - const: qcom,qcm2290-venus
> - const: qcom,qcm2290-venus
>
> @@ -45,9 +44,6 @@ properties:
> - const: vcodec0_core
> - const: vcodec0_bus
>
> - iommus:
> - maxItems: 2
> -
> interconnects:
> maxItems: 2
>
> @@ -65,6 +61,22 @@ required:
> - power-domain-names
> - iommus
>
> +allOf:
> + - $ref: qcom,venus-common.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,shikra-venus
> + then:
> + properties:
> + iommus:
> + maxItems: 1
> + else:
> + properties:
> + iommus:
> + maxItems: 2
> +
> unevaluatedProperties: false
>
> examples:
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -37,7 +37,10 @@ properties:
> maxItems: 20
>
> memory-region:
> - maxItems: 1
> + minItems: 1
> + items:
> + - description: Firmware-loaded codec carveout
> + - description: IOMMU IOVA reservation region
This adds second region to several other devices using
qcom,venus-common.yaml, thus should be its own commit with its own
rationale why all devices take the IOMMU IOVA region now.
>
> power-domains:
> minItems: 1
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-22 7:15 ` Krzysztof Kozlowski
@ 2026-07-22 10:57 ` Vikash Garodia
0 siblings, 0 replies; 11+ messages in thread
From: Vikash Garodia @ 2026-07-22 10:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On 7/22/2026 12:45 PM, Krzysztof Kozlowski wrote:
> On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
>> Document the iris video accelerator used on shikra platforms by adding
>> the qcom,shikra-iris compatible.
>
> iris here, venus in the compatible. Please decide which one.
Ack. Should fix the commit here to mention it as qcom,shikra-venus.
>
>>
>> Although QCM2290 and shikra share the same video hardware and overall
>> integration, their SMMU programming differs. QCM2290 exposes separate
>> stream IDs for the video hardware and the Xtensa path, requiring two
>> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
>> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
>> and Xtensa isolation requirements, such SMR masking is not applicable on
>> QCM2290 platforms.
>
> This paragraph suggests devices are not compatible. Will Shikra Iris
> work fine when driver matches with qcom,qcm2290-venus?
>
Validated shikra with qcom,shikra-venus as fallback compatible to
qcom,qcm2290-venus.
>> Since shikra uses the same video hardware as QCM2290 and shares the same
>> programming model and capabilities, it is added as a fallback compatible
>> to qcom,qcm2290-venus, with conditional handling to allow either one or
>> two IOMMU entries.
>> Common schema is updated to accommodate the iova restriction of 600MB.
>> VPU restricts usage of 600MB for specific streams, which could otherwise
>> lead to device crash.
>>
>> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
>> .../bindings/media/qcom,venus-common.yaml | 5 ++++-
>> 2 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
>> index 5977e7d0a71b4fb5681f1c2094439c251366f01f..b27899ebf164229ceff1ca5cda50ee30d875e953 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
>> @@ -13,14 +13,13 @@ description:
>> The Venus AR50_LITE IP is a video encode and decode accelerator present
>> on Qualcomm platforms.
>>
>> -allOf:
>> - - $ref: qcom,venus-common.yaml#
>> -
>> properties:
>> compatible:
>> oneOf:
>> - items:
>> - - const: qcom,sm6115-venus
>> + - enum:
>> + - qcom,shikra-venus
>> + - qcom,sm6115-venus
>> - const: qcom,qcm2290-venus
>> - const: qcom,qcm2290-venus
>>
>> @@ -45,9 +44,6 @@ properties:
>> - const: vcodec0_core
>> - const: vcodec0_bus
>>
>> - iommus:
>> - maxItems: 2
>> -
>> interconnects:
>> maxItems: 2
>>
>> @@ -65,6 +61,22 @@ required:
>> - power-domain-names
>> - iommus
>>
>> +allOf:
>> + - $ref: qcom,venus-common.yaml#
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: qcom,shikra-venus
>> + then:
>> + properties:
>> + iommus:
>> + maxItems: 1
>> + else:
>> + properties:
>> + iommus:
>> + maxItems: 2
>> +
>> unevaluatedProperties: false
>>
>> examples:
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> @@ -37,7 +37,10 @@ properties:
>> maxItems: 20
>>
>> memory-region:
>> - maxItems: 1
>> + minItems: 1
>> + items:
>> + - description: Firmware-loaded codec carveout
>> + - description: IOMMU IOVA reservation region
>
> This adds second region to several other devices using
> qcom,venus-common.yaml, thus should be its own commit with its own
> rationale why all devices take the IOMMU IOVA region now.
>
Sure, i can split the common yaml as a separate preceding commit with
justification on need of separate IOVA region.
Regards,
Vikash
>>
>> power-domains:
>> minItems: 1
>>
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
2026-07-22 7:15 ` Krzysztof Kozlowski
@ 2026-07-31 11:57 ` Dmitry Baryshkov
2026-07-31 12:44 ` Vikash Garodia
2026-07-31 13:39 ` Bryan O'Donoghue
2 siblings, 1 reply; 11+ messages in thread
From: Dmitry Baryshkov @ 2026-07-31 11:57 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
> Document the iris video accelerator used on shikra platforms by adding
> the qcom,shikra-iris compatible.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
This means that there are still two different streams, one for pixel and
one for non-pixel data. Stop using the mask and describe them
separately. One will go to the pixel node, another will go to the
non-pixel node. As you wrote, the hardware is the same as QCM2290, which
has two separate streams.
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
> Common schema is updated to accommodate the iova restriction of 600MB.
> VPU restricts usage of 600MB for specific streams, which could otherwise
> lead to device crash.
>
> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-31 11:57 ` Dmitry Baryshkov
@ 2026-07-31 12:44 ` Vikash Garodia
2026-07-31 14:10 ` Dmitry Baryshkov
0 siblings, 1 reply; 11+ messages in thread
From: Vikash Garodia @ 2026-07-31 12:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On 7/31/2026 5:27 PM, Dmitry Baryshkov wrote:
> On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
>> Document the iris video accelerator used on shikra platforms by adding
>> the qcom,shikra-iris compatible.
>>
>> Although QCM2290 and shikra share the same video hardware and overall
>> integration, their SMMU programming differs. QCM2290 exposes separate
>> stream IDs for the video hardware and the Xtensa path, requiring two
>> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
>> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
>> and Xtensa isolation requirements, such SMR masking is not applicable on
>> QCM2290 platforms.
>
> This means that there are still two different streams, one for pixel and
> one for non-pixel data. Stop using the mask and describe them
> separately. One will go to the pixel node, another will go to the
> non-pixel node. As you wrote, the hardware is the same as QCM2290, which
> has two separate streams.
AFAIU, SMR mask is an optimization to reduce the stream id configuration
to SMMU hardware registers, separating out is _not_ recommended which
again brings in additional register for programming the additional stream.
Regards,
Vikash>
>> Since shikra uses the same video hardware as QCM2290 and shares the same
>> programming model and capabilities, it is added as a fallback compatible
>> to qcom,qcm2290-venus, with conditional handling to allow either one or
>> two IOMMU entries.
>> Common schema is updated to accommodate the iova restriction of 600MB.
>> VPU restricts usage of 600MB for specific streams, which could otherwise
>> lead to device crash.
>>
>> Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
2026-07-22 7:15 ` Krzysztof Kozlowski
2026-07-31 11:57 ` Dmitry Baryshkov
@ 2026-07-31 13:39 ` Bryan O'Donoghue
2026-07-31 14:01 ` Bryan O'Donoghue
2 siblings, 1 reply; 11+ messages in thread
From: Bryan O'Donoghue @ 2026-07-31 13:39 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vishnu Reddy
On 21/07/2026 18:32, Vikash Garodia wrote:
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> @@ -37,7 +37,10 @@ properties:
> maxItems: 20
>
> memory-region:
> - maxItems: 1
> + minItems: 1
> + items:
> + - description: Firmware-loaded codec carveout
> + - description: IOMMU IOVA reservation region
So we discussed separately the pixel and non-pixel sub-nodes as well as
this basically alternate means of memory delination.
What I'd like is a clear statement
- Committing to this scheme for existing platforms
- Adding the pixel and sub-pixel to the shared
- Backporting at least one method to -stable
For that reason this extension should at a minimum be its own commit
with a well articulated commit log.
Since this is minItems: 1 it is conceviable to land both this and the
sub-node into the same file.
But my continued feedback and objection is not being clear about what's
being done and having two separate methods without a clear roadmap.
You have your sub-node RFC and this change - I won't say sneaking in
here but, its a surreptitious change as given as-is.
- Which method
- Both ? Then what goes to -stable
We also discussed offline the fact that right-now the lack of a means of
addressing this in upstream means we are in effect leaving a known
critical bug open to the vagaries of IOVA allocation @ runtime across
every single venus and iris there is.
So to me minItems: 1 for -stable _in_this_kernel_cycle_ is warranted.
---
bod
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-31 13:39 ` Bryan O'Donoghue
@ 2026-07-31 14:01 ` Bryan O'Donoghue
0 siblings, 0 replies; 11+ messages in thread
From: Bryan O'Donoghue @ 2026-07-31 14:01 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel,
Vishnu Reddy
On 31/07/2026 14:39, Bryan O'Donoghue wrote:
> On 21/07/2026 18:32, Vikash Garodia wrote:
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-
>> common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-
>> common.yaml
>> index
>> 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> @@ -37,7 +37,10 @@ properties:
>> maxItems: 20
>>
>> memory-region:
>> - maxItems: 1
>> + minItems: 1
>> + items:
>> + - description: Firmware-loaded codec carveout
>> + - description: IOMMU IOVA reservation region
>
> So we discussed separately the pixel and non-pixel sub-nodes as well as
> this basically alternate means of memory delination.
>
> What I'd like is a clear statement
>
> - Committing to this scheme for existing platforms
> - Adding the pixel and sub-pixel to the shared
> - Backporting at least one method to -stable
>
> For that reason this extension should at a minimum be its own commit
> with a well articulated commit log.
>
> Since this is minItems: 1 it is conceviable to land both this and the
> sub-node into the same file.
>
> But my continued feedback and objection is not being clear about what's
> being done and having two separate methods without a clear roadmap.
>
> You have your sub-node RFC and this change - I won't say sneaking in
> here but, its a surreptitious change as given as-is.
>
> - Which method
> - Both ? Then what goes to -stable
>
> We also discussed offline the fact that right-now the lack of a means of
> addressing this in upstream means we are in effect leaving a known
> critical bug open to the vagaries of IOVA allocation @ runtime across
> every single venus and iris there is.
>
> So to me minItems: 1 for -stable _in_this_kernel_cycle_ is warranted.
>
> ---
> bod
Just thinking about our conversation on this topic..
Truth be told, I don't think any new features should be merged to venus
or iris until this gets a resolution applicable to -stable. Its just not
kosher to pretend everything is fine and keep merging new features with
a known critical error festering unaddressed. Fixes: yes, other stuff no.
Bug fixes > New features many times over.
This absolutely has to go to the top of the queue, its going on for
months unresolved - what use is a new video codec to a user on a system
where we can mess up the IOVA/SID mappings and trigger a hard reset ?
Its not just that its a bug, its that its a system resetting bug.
I'm going to have to insist.
---
bod
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
2026-07-31 12:44 ` Vikash Garodia
@ 2026-07-31 14:10 ` Dmitry Baryshkov
0 siblings, 0 replies; 11+ messages in thread
From: Dmitry Baryshkov @ 2026-07-31 14:10 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Bryan O'Donoghue, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Stanimir Varbanov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-media, devicetree,
linux-kernel, Vishnu Reddy
On Fri, Jul 31, 2026 at 06:14:15PM +0530, Vikash Garodia wrote:
>
> On 7/31/2026 5:27 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 21, 2026 at 11:02:25PM +0530, Vikash Garodia wrote:
> > > Document the iris video accelerator used on shikra platforms by adding
> > > the qcom,shikra-iris compatible.
> > >
> > > Although QCM2290 and shikra share the same video hardware and overall
> > > integration, their SMMU programming differs. QCM2290 exposes separate
> > > stream IDs for the video hardware and the Xtensa path, requiring two
> > > explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> > > equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> > > and Xtensa isolation requirements, such SMR masking is not applicable on
> > > QCM2290 platforms.
> >
> > This means that there are still two different streams, one for pixel and
> > one for non-pixel data. Stop using the mask and describe them
> > separately. One will go to the pixel node, another will go to the
> > non-pixel node. As you wrote, the hardware is the same as QCM2290, which
> > has two separate streams.
>
> AFAIU, SMR mask is an optimization to reduce the stream id configuration to
> SMMU hardware registers, separating out is _not_ recommended which again
> brings in additional register for programming the additional stream.
We will need to separate it later anyway, to handle two different IOVA
regions. So why not perform it right from the beginning?
We should not be introducing a mechanism (memory-region) which is
limited only to this platform, if all other plaforms will use something
different (subnodes).
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2026-07-31 14:10 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-21 17:32 [PATCH v4 0/3] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible Vikash Garodia
2026-07-22 7:15 ` Krzysztof Kozlowski
2026-07-22 10:57 ` Vikash Garodia
2026-07-31 11:57 ` Dmitry Baryshkov
2026-07-31 12:44 ` Vikash Garodia
2026-07-31 14:10 ` Dmitry Baryshkov
2026-07-31 13:39 ` Bryan O'Donoghue
2026-07-31 14:01 ` Bryan O'Donoghue
2026-07-21 17:32 ` [PATCH v4 2/3] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
2026-07-21 17:32 ` [PATCH v4 3/3] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox