* [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra
@ 2026-07-22 13:41 Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
` (4 more replies)
0 siblings, 5 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 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 v5:
- Moved the common schema changes as separate patch (Krzysztof)
- Link to v4: https://lore.kernel.org/r/20260721-shikra_vpu-v4-0-6dc5a8999b73@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 (4):
dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
dt-bindings: media: qcom,qcm2290-venus: document shikra venus 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] 14+ messages in thread
* [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-22 22:03 ` Bryan O'Donoghue
2026-07-24 5:59 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
` (3 subsequent siblings)
4 siblings, 2 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 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
Update the memory-region property to support two regions:
1. Firmware-loaded codec carveout (existing)
2. IOMMU IOVA reservation region (new)
The IOMMU IOVA reservation region is required to restrict usage of
specific IOVA memory range. For example, VPU restricts usage of 600MB
for specific streams, which could otherwise lead to device crash. This
change allows platforms to define separate memory regions for codec
carveout and IOVA restrictions.
This schema update supports existing DTS having single memory-region,
thereby allowing gradual migration of DTS to support two memory region.
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Documentation/devicetree/bindings/media/qcom,venus-common.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
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] 14+ messages in thread
* [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-24 6:03 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
` (2 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 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 venus video accelerator used on shikra platforms by adding
the qcom,shikra-venus 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.
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 ++++++++++++++++------
1 file changed, 19 insertions(+), 7 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:
--
2.34.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
2026-09-17 10:39 ` [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 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] 14+ messages in thread
* [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
` (2 preceding siblings ...)
2026-07-22 13:41 ` [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
@ 2026-07-22 13:41 ` Vikash Garodia
2026-09-17 10:39 ` [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-22 13:41 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] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
@ 2026-07-22 22:03 ` Bryan O'Donoghue
2026-07-23 9:06 ` Konrad Dybcio
2026-07-24 5:59 ` Krzysztof Kozlowski
1 sibling, 1 reply; 14+ messages in thread
From: Bryan O'Donoghue @ 2026-07-22 22:03 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
On 22/07/2026 14:41, Vikash Garodia wrote:
> Update the memory-region property to support two regions:
> 1. Firmware-loaded codec carveout (existing)
> 2. IOMMU IOVA reservation region (new)
>
> The IOMMU IOVA reservation region is required to restrict usage of
> specific IOVA memory range. For example, VPU restricts usage of 600MB
> for specific streams, which could otherwise lead to device crash. This
> change allows platforms to define separate memory regions for codec
> carveout and IOVA restrictions.
> This schema update supports existing DTS having single memory-region,
> thereby allowing gradual migration of DTS to support two memory region.
>
> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
> ---
I'm not mega-happy with this pattern being used - I prefer the pixel
pixel_cb sub-node model you've proposed yourself.
OTOH you're the maintainer so its really up to you how you want to
arbitrate this - the 600MB constraint will work even if its not pretty
or the best thing (tm).
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 22:03 ` Bryan O'Donoghue
@ 2026-07-23 9:06 ` Konrad Dybcio
2026-07-23 10:44 ` Vikash Garodia
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-23 9:06 UTC (permalink / raw)
To: Bryan O'Donoghue, 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
On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
> On 22/07/2026 14:41, Vikash Garodia wrote:
>> Update the memory-region property to support two regions:
>> 1. Firmware-loaded codec carveout (existing)
>> 2. IOMMU IOVA reservation region (new)
>>
>> The IOMMU IOVA reservation region is required to restrict usage of
>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>> for specific streams, which could otherwise lead to device crash. This
>> change allows platforms to define separate memory regions for codec
>> carveout and IOVA restrictions.
>> This schema update supports existing DTS having single memory-region,
>> thereby allowing gradual migration of DTS to support two memory region.
>>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> ---
>
> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>
> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Doesn't this cause the same limitation that the initial patch
by Daniel (all HW contexts can't access 0-600MiB anymore)?
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-23 9:06 ` Konrad Dybcio
@ 2026-07-23 10:44 ` Vikash Garodia
2026-07-29 12:21 ` Konrad Dybcio
0 siblings, 1 reply; 14+ messages in thread
From: Vikash Garodia @ 2026-07-23 10:44 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, 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
On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>> Update the memory-region property to support two regions:
>>> 1. Firmware-loaded codec carveout (existing)
>>> 2. IOMMU IOVA reservation region (new)
>>>
>>> The IOMMU IOVA reservation region is required to restrict usage of
>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>> for specific streams, which could otherwise lead to device crash. This
>>> change allows platforms to define separate memory regions for codec
>>> carveout and IOVA restrictions.
>>> This schema update supports existing DTS having single memory-region,
>>> thereby allowing gradual migration of DTS to support two memory region.
>>>
>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>> ---
>>
>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>
>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Doesn't this cause the same limitation that the initial patch
> by Daniel (all HW contexts can't access 0-600MiB anymore)?
Yes, it does, but for cases, like Shikra, which have single streams
(with SMRs), there is no additional benefit in going with sub nodes in
such case.
Regards,
Vikash
>
> Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
2026-07-22 22:03 ` Bryan O'Donoghue
@ 2026-07-24 5:59 ` Krzysztof Kozlowski
1 sibling, 0 replies; 14+ messages in thread
From: Krzysztof Kozlowski @ 2026-07-24 5:59 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
On Wed, Jul 22, 2026 at 07:11:18PM +0530, Vikash Garodia wrote:
> Update the memory-region property to support two regions:
> 1. Firmware-loaded codec carveout (existing)
> 2. IOMMU IOVA reservation region (new)
>
> The IOMMU IOVA reservation region is required to restrict usage of
> specific IOVA memory range. For example, VPU restricts usage of 600MB
> for specific streams, which could otherwise lead to device crash. This
> change allows platforms to define separate memory regions for codec
> carveout and IOVA restrictions.
> This schema update supports existing DTS having single memory-region,
> thereby allowing gradual migration of DTS to support two memory region.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/media/qcom,venus-common.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
@ 2026-07-24 6:03 ` Krzysztof Kozlowski
0 siblings, 0 replies; 14+ messages in thread
From: Krzysztof Kozlowski @ 2026-07-24 6:03 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 Wed, Jul 22, 2026 at 07:11:19PM +0530, Vikash Garodia wrote:
> Document the venus video accelerator used on shikra platforms by adding
> the qcom,shikra-venus 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.
>
> 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 ++++++++++++++++------
> 1 file changed, 19 insertions(+), 7 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-23 10:44 ` Vikash Garodia
@ 2026-07-29 12:21 ` Konrad Dybcio
2026-07-29 12:21 ` Konrad Dybcio
2026-07-30 8:50 ` Vikash Garodia
0 siblings, 2 replies; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-29 12:21 UTC (permalink / raw)
To: Vikash Garodia, Bryan O'Donoghue, 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
On 7/23/26 12:44 PM, Vikash Garodia wrote:
>
> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>> Update the memory-region property to support two regions:
>>>> 1. Firmware-loaded codec carveout (existing)
>>>> 2. IOMMU IOVA reservation region (new)
>>>>
>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>> for specific streams, which could otherwise lead to device crash. This
>>>> change allows platforms to define separate memory regions for codec
>>>> carveout and IOVA restrictions.
>>>> This schema update supports existing DTS having single memory-region,
>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>
>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>
>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>
>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>
>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>
>> Doesn't this cause the same limitation that the initial patch
>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>
> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
Please note that somewhere, I was under the impression all venus
impls suffer from that
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-29 12:21 ` Konrad Dybcio
@ 2026-07-29 12:21 ` Konrad Dybcio
2026-07-30 8:50 ` Vikash Garodia
1 sibling, 0 replies; 14+ messages in thread
From: Konrad Dybcio @ 2026-07-29 12:21 UTC (permalink / raw)
To: Vikash Garodia, Bryan O'Donoghue, 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
On 7/29/26 2:21 PM, Konrad Dybcio wrote:
> On 7/23/26 12:44 PM, Vikash Garodia wrote:
>>
>> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>>> Update the memory-region property to support two regions:
>>>>> 1. Firmware-loaded codec carveout (existing)
>>>>> 2. IOMMU IOVA reservation region (new)
>>>>>
>>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>>> for specific streams, which could otherwise lead to device crash. This
>>>>> change allows platforms to define separate memory regions for codec
>>>>> carveout and IOVA restrictions.
>>>>> This schema update supports existing DTS having single memory-region,
>>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>>
>>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>>
>>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>>
>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>
>>> Doesn't this cause the same limitation that the initial patch
>>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>>
>> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
>
> Please note that somewhere, I was under the impression all venus
> impls suffer from that
Or.. is that a difference of "linux uses iommu-map today" vs "doesnt"?
Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
2026-07-29 12:21 ` Konrad Dybcio
2026-07-29 12:21 ` Konrad Dybcio
@ 2026-07-30 8:50 ` Vikash Garodia
1 sibling, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-07-30 8:50 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, 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
On 7/29/2026 5:51 PM, Konrad Dybcio wrote:
> On 7/23/26 12:44 PM, Vikash Garodia wrote:
>>
>> On 7/23/2026 2:36 PM, Konrad Dybcio wrote:
>>> On 7/23/26 12:03 AM, Bryan O'Donoghue wrote:
>>>> On 22/07/2026 14:41, Vikash Garodia wrote:
>>>>> Update the memory-region property to support two regions:
>>>>> 1. Firmware-loaded codec carveout (existing)
>>>>> 2. IOMMU IOVA reservation region (new)
>>>>>
>>>>> The IOMMU IOVA reservation region is required to restrict usage of
>>>>> specific IOVA memory range. For example, VPU restricts usage of 600MB
>>>>> for specific streams, which could otherwise lead to device crash. This
>>>>> change allows platforms to define separate memory regions for codec
>>>>> carveout and IOVA restrictions.
>>>>> This schema update supports existing DTS having single memory-region,
>>>>> thereby allowing gradual migration of DTS to support two memory region.
>>>>>
>>>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> I'm not mega-happy with this pattern being used - I prefer the pixel pixel_cb sub-node model you've proposed yourself.
>>>>
>>>> OTOH you're the maintainer so its really up to you how you want to arbitrate this - the 600MB constraint will work even if its not pretty or the best thing (tm).
>>>>
>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>
>>> Doesn't this cause the same limitation that the initial patch
>>> by Daniel (all HW contexts can't access 0-600MiB anymore)?
>>
>> Yes, it does, but for cases, like Shikra, which have single streams (with SMRs), there is no additional benefit in going with sub nodes in such case.
>
> Please note that somewhere, I was under the impression all venus
> impls suffer from that
Yes, all of venus/iris, including Shikra, have this limitation. I was
trying to convey that for single stream case, like that of Shikra, we
can specify the restrictive IOVA range in the parent iris node itself
instead of introducing a sub node and put the same restriction there.
Regards,
Vikash
>
> Konrad
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
` (3 preceding siblings ...)
2026-07-22 13:41 ` [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
@ 2026-09-17 10:39 ` Vikash Garodia
4 siblings, 0 replies; 14+ messages in thread
From: Vikash Garodia @ 2026-09-17 10:39 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,
Vishnu Reddy, Konrad Dybcio, Dmitry Baryshkov
On 7/22/2026 7:11 PM, Vikash Garodia wrote:
> Vikash Garodia (4):
> dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region
> dt-bindings: media: qcom,qcm2290-venus: document shikra venus 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(-)
Hello Bryan,
Could you please update when we can expect the binding patch to be applied ?
#1 patch in this series can be dropped once you apply the 600MB iova fix
in iris/venus driver.
Once the #2 binding is applied, i will reach out to DT maintainers to
apply the DTS.
Regards,
Vikash
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2026-09-17 10:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-22 13:41 [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 1/4] dt-bindings: media: qcom,venus-common: Add IOMMU IOVA reservation region Vikash Garodia
2026-07-22 22:03 ` Bryan O'Donoghue
2026-07-23 9:06 ` Konrad Dybcio
2026-07-23 10:44 ` Vikash Garodia
2026-07-29 12:21 ` Konrad Dybcio
2026-07-29 12:21 ` Konrad Dybcio
2026-07-30 8:50 ` Vikash Garodia
2026-07-24 5:59 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 2/4] dt-bindings: media: qcom,qcm2290-venus: document shikra venus compatible Vikash Garodia
2026-07-24 6:03 ` Krzysztof Kozlowski
2026-07-22 13:41 ` [PATCH v5 3/4] arm64: dts: qcom: shikra: Add Iris video codec node Vikash Garodia
2026-07-22 13:41 ` [PATCH v5 4/4] arm64: dts: qcom: shikra-evk: Enable Iris core Vikash Garodia
2026-09-17 10:39 ` [PATCH v5 0/4] media: qcom: Add support for the iris codec on shikra Vikash Garodia
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox