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

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

[Vikash Garodia]

Qualcomm kaanapali platform have a newer generation of video IP iris4. 
The hardware have evolved mostly with respect to higher number of power 
domains as well as multiple clock sources.

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

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

Following are the compliance and functional validation reports.

v4l2-compliance report for decoder including streaming tests:

v4l2-compliance 1.33.0-5441, 64 bits, 64-bit time_t
v4l2-compliance SHA: 4310f15610f4 2026-01-18 22:09:17

Compliance test for iris_driver device /dev/video0:

Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Decoder
        Bus info         : platform:2000000.video-codec
        Driver version   : 6.19.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: 12 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 465 buffers
        test MMAP (select, REQBUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (epoll, REQBUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (select, CREATE_BUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 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

v4l2-compliance report for encoder including streaming tests:

v4l2-compliance 1.33.0-5441, 64 bits, 64-bit time_t
v4l2-compliance SHA: 4310f15610f4 2026-01-18 22:09:17

Compliance test for iris_driver device /dev/video1:

Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Encoder
        Bus info         : platform:2000000.video-codec
        Driver version   : 6.19.0
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateful Encoder

Required ioctls:
        test VIDIOC_QUERYCAP: OK
        test invalid ioctls: OK

Allow for multiple opens:
        test second /dev/video1 open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK
        test for unlimited opens: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
        test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
        test VIDIOC_QUERYCTRL: OK
        test VIDIOC_G/S_CTRL: OK
        test VIDIOC_G/S/TRY_EXT_CTRLS: OK
        test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
        test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
        Standard Controls: 38 Private Controls: 0

Format ioctls:
        test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
        test VIDIOC_G/S_PARM: OK
        test VIDIOC_G_FBUF: OK (Not Supported)
        test VIDIOC_G_FMT: OK
        test VIDIOC_TRY_FMT: OK
        test VIDIOC_S_FMT: OK
        test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
        test Cropping: OK
        test Composing: OK (Not Supported)
        test Scaling: OK (Not Supported)

Codec ioctls:
        test VIDIOC_(TRY_)ENCODER_CMD: OK
        test VIDIOC_G_ENC_INDEX: OK (Not Supported)
        test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
        test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
        test CREATE_BUFS maximum buffers: OK
        test VIDIOC_REMOVE_BUFS: OK
        test VIDIOC_EXPBUF: OK
        test Requests: OK (Not Supported)
        test blocking wait: OK

Test input 0:

Streaming ioctls:
        test read/write: OK (Not Supported)
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (select, REQBUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (epoll, REQBUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (select, CREATE_BUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (epoll, CREATE_BUFS): OK
        test USERPTR (select): OK (Not Supported)
        test DMABUF: Cannot test, specify --expbuf-device

Total for iris_driver device /dev/video1: 54, Succeeded: 54, Failed: 0, 
Warnings: 0

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

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

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

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

gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
capture-io-mode=4 output-io-mode=4 ! filesink sync=true
location=<output_file.hevc>

ffmpeg test:
Decoders validated with below commands:
ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0
output_file.yuv -y

v4l2-ctl test
Decoders validated with below commands:
v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=<input_file.h264> --stream-to=<output_file.yuv>

v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=input_file.bit --stream-to=<output_file.yuv>

v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from-hdr=input_file.hdr  --stream-mmap
--stream-to=<output_file.yuv>

Encoders validated with below commands:
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d
/dev/video1
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d
/dev/video1

Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Charan Teja Kalla (2):
      of: factor out of_map_id() code
      of/iommu: add multi-map support

Vikash Garodia (5):
      media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding
      media: iris: Switch to hardware mode after firmware boot
      media: iris: add context bank devices using iommu-map
      media: iris: add helper to select context bank device
      media: iris: Add platform data for kaanapali

 .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
 drivers/iommu/of_iommu.c                           |  36 +++-
 drivers/media/platform/qcom/iris/iris_buffer.c     |   7 +-
 drivers/media/platform/qcom/iris/iris_buffer.h     |   2 +
 drivers/media/platform/qcom/iris/iris_core.c       |   4 +
 drivers/media/platform/qcom/iris/iris_hfi_common.c |   4 +
 drivers/media/platform/qcom/iris/iris_hfi_queue.c  |  16 +-
 .../platform/qcom/iris/iris_platform_common.h      |  30 +++
 .../media/platform/qcom/iris/iris_platform_gen2.c  |  90 ++++++++
 .../platform/qcom/iris/iris_platform_kaanapali.h   |  80 +++++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  59 +++++-
 drivers/media/platform/qcom/iris/iris_resources.c  |  93 ++++++++
 drivers/media/platform/qcom/iris/iris_resources.h  |   3 +
 drivers/media/platform/qcom/iris/iris_vidc.c       |   4 +-
 drivers/media/platform/qcom/iris/iris_vpu2.c       |   1 +
 drivers/media/platform/qcom/iris/iris_vpu3x.c      |   9 +-
 drivers/media/platform/qcom/iris/iris_vpu4x.c      |  24 ++-
 drivers/media/platform/qcom/iris/iris_vpu_common.c |  16 +-
 drivers/media/platform/qcom/iris/iris_vpu_common.h |   3 +
 drivers/of/base.c                                  |  69 ++++--
 include/linux/of.h                                 |   6 +
 21 files changed, 726 insertions(+), 64 deletions(-)
---
base-commit: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
change-id: 20260126-kaanapali-iris-29fd184e2fe4
prerequisite-message-id: <20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com>
prerequisite-patch-id: 1d896ff4a958ebd06066dbf705c4c45cf73b6041
prerequisite-patch-id: 44414df7d8342ca19c0518ac087f08f98546c3ff
prerequisite-patch-id: 0f45ca6f67948e03a89274c144660a55b3ff8fb1

Best regards,
-- 
Vikash Garodia <vikash.garodia@oss.qualcomm.com>

[PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Vikash Garodia]

Kaanapali SOC brings in the new generation of video IP i.e iris4. When
compared to previous generation, iris3x, it has,
- separate power domains for stream and pixel processing hardware blocks
  (bse and vpp).
- additional power domain for apv codec.
- power domains for individual pipes (VPPx).
- different clocks and reset lines.

iommu-map include all the different stream-ids which can be possibly
generated by vpu4 hardware.

Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
 1 file changed, 234 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..4ed2afacb19043a60cfd67c4492356b4adb81c3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.yaml
@@ -0,0 +1,234 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-iris.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Iris video encoder and decoder
+
+maintainers:
+  - Vikash Garodia <vikash.garodia@oss.qualcomm.com>
+  - Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
+
+description:
+  The iris video processing unit is a video encode and decode accelerator
+  present on Qualcomm Kaanapali SoC.
+
+properties:
+  compatible:
+    const: qcom,kaanapali-iris
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 10
+
+  clock-names:
+    items:
+      - const: iface
+      - const: core
+      - const: vcodec0_core
+      - const: iface1
+      - const: core_freerun
+      - const: vcodec0_core_freerun
+      - const: vcodec_bse
+      - const: vcodec_vpp0
+      - const: vcodec_vpp1
+      - const: vcodec_apv
+
+  dma-coherent: true
+
+  firmware-name:
+    maxItems: 1
+
+  interconnects:
+    maxItems: 2
+
+  interconnect-names:
+    items:
+      - const: cpu-cfg
+      - const: video-mem
+
+  interrupts:
+    maxItems: 1
+
+  iommu-map: true
+
+  memory-region:
+    maxItems: 1
+
+  operating-points-v2: true
+  opp-table:
+    type: object
+
+  power-domains:
+    maxItems: 7
+
+  power-domain-names:
+    items:
+      - const: venus
+      - const: vcodec0
+      - const: mxc
+      - const: mmcx
+      - const: vpp0
+      - const: vpp1
+      - const: apv
+
+  resets:
+    maxItems: 4
+
+  reset-names:
+    items:
+      - const: bus0
+      - const: bus1
+      - const: core
+      - const: vcodec0_core
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - dma-coherent
+  - interconnects
+  - interconnect-names
+  - interrupts
+  - iommu-map
+  - memory-region
+  - power-domains
+  - power-domain-names
+  - resets
+  - reset-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/power/qcom,rpmhpd.h>
+
+    video-codec@2000000 {
+        compatible = "qcom,kaanapali-iris";
+        reg = <0x02000000 0xf0000>;
+
+        clocks = <&gcc_video_axi0_clk>,
+                 <&video_cc_mvs0c_clk>,
+                 <&video_cc_mvs0_clk>,
+                 <&gcc_video_axi1_clk>,
+                 <&video_cc_mvs0c_freerun_clk>,
+                 <&video_cc_mvs0_freerun_clk>,
+                 <&video_cc_mvs0b_clk>,
+                 <&video_cc_mvs0_vpp0_clk>,
+                 <&video_cc_mvs0_vpp1_clk>,
+                 <&video_cc_mvs0a_clk>;
+        clock-names = "iface",
+                      "core",
+                      "vcodec0_core",
+                      "iface1",
+                      "core_freerun",
+                      "vcodec0_core_freerun",
+                      "vcodec_bse",
+                      "vcodec_vpp0",
+                      "vcodec_vpp1",
+                      "vcodec_apv";
+
+        dma-coherent;
+
+        interconnects = <&gem_noc_master_appss_proc &config_noc_slave_venus_cfg>,
+                        <&mmss_noc_master_video_mvp &mc_virt_slave_ebi1>;
+        interconnect-names = "cpu-cfg",
+                             "video-mem";
+
+        interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
+                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
+                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
+                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
+                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
+                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
+                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
+                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
+                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
+
+        memory-region = <&video_mem>;
+
+        operating-points-v2 = <&iris_opp_table>;
+
+        power-domains = <&video_cc_mvs0c_gdsc>,
+                        <&video_cc_mvs0_gdsc>,
+                        <&rpmhpd RPMHPD_MXC>,
+                        <&rpmhpd RPMHPD_MMCX>,
+                        <&video_cc_mvs0_vpp0_gdsc>,
+                        <&video_cc_mvs0_vpp1_gdsc>,
+                        <&video_cc_mvs0a_gdsc>;
+        power-domain-names = "venus",
+                             "vcodec0",
+                             "mxc",
+                             "mmcx",
+                             "vpp0",
+                             "vpp1",
+                             "apv";
+
+        resets = <&gcc_video_axi0_clk_ares>,
+                 <&gcc_video_axi1_clk_ares>,
+                 <&video_cc_mvs0c_freerun_clk_ares>,
+                 <&video_cc_mvs0_freerun_clk_ares>;
+        reset-names = "bus0",
+                      "bus1",
+                      "core",
+                      "vcodec0_core";
+
+        iris_opp_table: opp-table {
+            compatible = "operating-points-v2";
+
+            opp-240000000 {
+                opp-hz = /bits/ 64 <240000000 240000000 240000000 360000000>;
+                required-opps = <&rpmhpd_opp_low_svs_d1>,
+                                <&rpmhpd_opp_low_svs_d1>;
+            };
+
+            opp-338000000 {
+                opp-hz = /bits/ 64 <338000000 338000000 338000000 507000000>;
+                required-opps = <&rpmhpd_opp_low_svs>,
+                                <&rpmhpd_opp_low_svs>;
+            };
+
+            opp-420000000 {
+                opp-hz = /bits/ 64 <420000000 420000000 420000000 630000000>;
+                required-opps = <&rpmhpd_opp_svs>,
+                                <&rpmhpd_opp_svs>;
+            };
+
+            opp-444000000 {
+                opp-hz = /bits/ 64 <444000000 444000000 444000000 666000000>;
+                required-opps = <&rpmhpd_opp_svs_l1>,
+                                <&rpmhpd_opp_svs_l1>;
+            };
+
+            opp-533000000 {
+                opp-hz = /bits/ 64 <533000000 533000000 533000000 800000000>;
+                required-opps = <&rpmhpd_opp_nom>,
+                                <&rpmhpd_opp_nom>;
+            };
+
+            opp-630000000 {
+                opp-hz = /bits/ 64 <630000000 630000000 630000000 1104000000>;
+                required-opps = <&rpmhpd_opp_turbo>,
+                                <&rpmhpd_opp_turbo>;
+            };
+
+            opp-800000000 {
+                opp-hz = /bits/ 64 <800000000 630000000 630000000 1260000000>;
+                required-opps = <&rpmhpd_opp_turbo_l0>,
+                                <&rpmhpd_opp_turbo_l0>;
+            };
+
+            opp-1000000000 {
+                opp-hz = /bits/ 64 <1000000000 630000000 850000000 1260000000>;
+                required-opps = <&rpmhpd_opp_turbo_l1>,
+                                <&rpmhpd_opp_turbo_l1>;
+            };
+        };
+    };

-- 
2.34.1

[PATCH 2/7] of: factor out of_map_id() code

[Vikash Garodia]

From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>

Linux interprets multiple mappings for the same input ID as a set of
equivalent choices to pick one. There exists usecases where these set
must be maintained in parallel, ex: on ARM, a dynamically created child
device(s) is referencing multiple input id's in parent iommu-map.

Factor out the code where multiple mappings needs to be maintained in
parallel can be achieved through callback from this factored out code.

Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 drivers/of/base.c | 47 ++++++++++++++++++++++++++++++++---------------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 0825f3dc93f2472e9947af09acdde72031ab85bc..606bef4f90e7d13bae4f7b0c45acd1755ad89826 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2122,6 +2122,32 @@ static bool of_check_bad_map(const __be32 *map, int len)
 	return true;
 }
 
+static int of_map_id_fill_output(struct of_map_id_arg *arg,
+				 struct device_node *phandle_node, u32 id_or_offset,
+				 const __be32 *out_base, u32 cells,
+				 bool bypass)
+{
+	if (bypass) {
+		arg->map_args.args[0] = id_or_offset;
+		return 0;
+	}
+
+	if (arg->map_args.np)
+		of_node_put(phandle_node);
+	else
+		arg->map_args.np = phandle_node;
+
+	if (arg->map_args.np != phandle_node)
+		return -EAGAIN;
+
+	for (int i = 0; i < cells; i++)
+		arg->map_args.args[i] = (id_or_offset + be32_to_cpu(out_base[i]));
+
+	arg->map_args.args_count = cells;
+
+	return 0;
+}
+
 /**
  * of_map_id - Translate an ID through a downstream mapping.
  * @np: root complex device node.
@@ -2162,8 +2188,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 		if (arg->map_args.np)
 			return -ENODEV;
 		/* Otherwise, no map implies no translation */
-		arg->map_args.args[0] = id;
-		return 0;
+		goto bypass_translation;
 	}
 
 	if (map_bytes % sizeof(*map))
@@ -2185,6 +2210,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 		struct device_node *phandle_node;
 		u32 id_base, phandle, id_len, id_off, cells = 0;
 		const __be32 *out_base;
+		int ret;
 
 		if (map_len - offset < 2)
 			goto err_map_len;
@@ -2238,19 +2264,10 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 		if (masked_id < id_base || id_off >= id_len)
 			continue;
 
-		if (arg->map_args.np)
-			of_node_put(phandle_node);
-		else
-			arg->map_args.np = phandle_node;
-
-		if (arg->map_args.np != phandle_node)
+		ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
+		if (ret == -EAGAIN)
 			continue;
 
-		for (int i = 0; i < cells; i++)
-			arg->map_args.args[i] = (id_off + be32_to_cpu(out_base[i]));
-
-		arg->map_args.args_count = cells;
-
 		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
 			np, map_name, map_mask, id_base, be32_to_cpup(out_base),
 			id_len, id, id_off + be32_to_cpup(out_base));
@@ -2260,9 +2277,9 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
 		id, arg->map_args.np  ? arg->map_args.np : NULL);
 
+bypass_translation:
 	/* Bypasses translation */
-	arg->map_args.args[0] = id;
-	return 0;
+	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
 
 err_map_len:
 	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);

-- 
2.34.1

[PATCH 3/7] of/iommu: add multi-map support

[Vikash Garodia]

From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>

When multiple mappings are present for an input id, linux matches just
the first one. There is a usecase[1] where all the mappings are to be
maintained in parallel for an iommu-map entry of a same input id.

Whether multi-map is needed is reported by the callers through the
callback function passed, which is called for every input id match.

Since the requirement in the usecase[1] is for platform devices, not
sure if it is really clean to maintain this decision on the bus type at
the of_iommu layer or further to be from the respective
iommu_driver->impl_ops().

[1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/

Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 drivers/iommu/of_iommu.c | 36 ++++++++++++++++++++++++++++--------
 drivers/of/base.c        | 38 ++++++++++++++++++++++++++++----------
 include/linux/of.h       |  6 ++++++
 3 files changed, 62 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 768eaddf927b0700b2497b08ea21611b1a1b5688..067bb2298973671e1eaf01bb2ea52df3d2a52a44 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -16,6 +16,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/fsl/mc.h>
+#include <linux/platform_device.h>
 
 #include "iommu-priv.h"
 
@@ -41,22 +42,41 @@ static int of_iommu_xlate(struct device *dev,
 	return ret;
 }
 
+/*
+ * Callback to be called from of_map_id(), that tells if
+ * all the mappings for an input id to be maintained in
+ * parallel. Should this decission be from further layers,
+ * iommu_driver->impl_ops?
+ */
+static int of_iommu_configure_cb(struct of_map_id_arg *arg)
+{
+	struct of_phandle_args *iommu_spec = &arg->map_args;
+	struct device *dev = arg->dev;
+	int err;
+
+	err = of_iommu_xlate(dev, iommu_spec);
+	of_node_put(iommu_spec->np);
+
+	/* !iommu_spec->np may be from the bypassed translations */
+	if (!err)
+		err = (!arg->multi_map || !iommu_spec->np) ? 0 : -EAGAIN;
+
+	return err;
+}
+
 static int of_iommu_configure_dev_id(struct device_node *master_np,
 				     struct device *dev,
 				     const u32 *id)
 {
 	struct of_map_id_arg arg = {
 		.map_args = {},
+		.cb = of_iommu_configure_cb,
+		.dev = dev,
+		/* Should this be pushed to iommu_driver->impl_ops? */
+		.multi_map = dev_is_platform(dev),
 	};
-	int err;
-
-	err = of_map_iommu_id(master_np, *id, &arg);
-	if (err)
-		return err;
 
-	err = of_iommu_xlate(dev, &arg.map_args);
-	of_node_put(arg.map_args.np);
-	return err;
+	return of_map_iommu_id(master_np, *id, &arg);
 }
 
 static int of_iommu_configure_dev(struct device_node *master_np,
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 606bef4f90e7d13bae4f7b0c45acd1755ad89826..a1c3c5954ec7e8eb3753c8fd782a1570f9eb9c17 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2122,14 +2122,21 @@ static bool of_check_bad_map(const __be32 *map, int len)
 	return true;
 }
 
-static int of_map_id_fill_output(struct of_map_id_arg *arg,
-				 struct device_node *phandle_node, u32 id_or_offset,
-				 const __be32 *out_base, u32 cells,
-				 bool bypass)
+/*
+ * Fill the id_out and target for the of_map_id() caller. Also
+ * call the callback passed to the of_map_id() as part of the arg
+ * that decides if to continue further search.
+ */
+static int of_map_id_fill_arg(struct of_map_id_arg *arg,
+			      struct device_node *phandle_node, u32 id_or_offset,
+			      const __be32 *out_base, u32 cells,
+			      bool bypass, bool *multi_id_map)
 {
+	int ret;
+
 	if (bypass) {
 		arg->map_args.args[0] = id_or_offset;
-		return 0;
+		goto output;
 	}
 
 	if (arg->map_args.np)
@@ -2145,7 +2152,14 @@ static int of_map_id_fill_output(struct of_map_id_arg *arg,
 
 	arg->map_args.args_count = cells;
 
-	return 0;
+output:
+	/* pass the output for the callback, callers may further decide */
+	ret =  arg->cb ? arg->cb(arg) : 0;
+
+	if (multi_id_map && ret == -EAGAIN)
+		*multi_id_map = true;
+
+	return ret;
 }
 
 /**
@@ -2179,6 +2193,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 	int map_bytes, map_len, offset = 0;
 	bool bad_map = false;
 	const __be32 *map = NULL;
+	bool multi_id_map = false;
 
 	if (!np || !map_name || !arg)
 		return -EINVAL;
@@ -2264,23 +2279,26 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
 		if (masked_id < id_base || id_off >= id_len)
 			continue;
 
-		ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
+		ret = of_map_id_fill_arg(arg, phandle_node, id_off, out_base,
+					 cells, false, &multi_id_map);
 		if (ret == -EAGAIN)
 			continue;
 
 		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
 			np, map_name, map_mask, id_base, be32_to_cpup(out_base),
 			id_len, id, id_off + be32_to_cpup(out_base));
-		return 0;
+		return ret;
 	}
 
+	if (multi_id_map)
+		return 0;
+
 	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
 		id, arg->map_args.np  ? arg->map_args.np : NULL);
 
 bypass_translation:
 	/* Bypasses translation */
-	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
-
+	return of_map_id_fill_arg(arg, NULL, id, 0, 0, true, NULL);
 err_map_len:
 	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
 	return -EINVAL;
diff --git a/include/linux/of.h b/include/linux/of.h
index 9efa6f93712c6024f05476f9fd39f3294f942ec1..abab73a76682351f5635c1127a6c899917525050 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -25,6 +25,9 @@
 typedef u32 phandle;
 typedef u32 ihandle;
 
+struct of_map_id_arg;
+typedef int (*of_map_id_cb)(struct of_map_id_arg *arg);
+
 struct property {
 	char	*name;
 	int	length;
@@ -76,6 +79,9 @@ struct of_phandle_args {
 
 struct of_map_id_arg {
 	struct of_phandle_args map_args;
+	of_map_id_cb cb;
+	struct device *dev;
+	bool multi_map;
 };
 
 struct of_phandle_iterator {

-- 
2.34.1

[PATCH 4/7] media: iris: Switch to hardware mode after firmware boot

[Vikash Garodia]

Currently the driver switches the vcodec GDSC to hardware (HW) mode
before firmware load and boot sequence. GDSC can be powered off,
keeping in hw mode, thereby the vcodec registers programmed in TrustZone
(TZ) carry default (reset) values.
Move the transition to HW mode after firmware load and boot sequence.

The bug was exposed with driver configuring different stream ids to
different devices via iommu-map. With registers carrying reset values,
VPU would not generate desired stream-id, thereby leading to SMMU fault.

Fixes: dde659d37036 ("media: iris: Introduce vpu ops for vpu4 with necessary hooks")
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 drivers/media/platform/qcom/iris/iris_core.c       |  4 ++++
 drivers/media/platform/qcom/iris/iris_hfi_common.c |  4 ++++
 drivers/media/platform/qcom/iris/iris_vpu2.c       |  1 +
 drivers/media/platform/qcom/iris/iris_vpu3x.c      |  9 +++-----
 drivers/media/platform/qcom/iris/iris_vpu4x.c      | 24 ++++++++++++----------
 drivers/media/platform/qcom/iris/iris_vpu_common.c | 16 +++++++++------
 drivers/media/platform/qcom/iris/iris_vpu_common.h |  3 +++
 7 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
index 8406c48d635b6eba0879396ce9f9ae2292743f09..dbaac01eb15a0e622e85635fddd29c1f7fc18662 100644
--- a/drivers/media/platform/qcom/iris/iris_core.c
+++ b/drivers/media/platform/qcom/iris/iris_core.c
@@ -75,6 +75,10 @@ int iris_core_init(struct iris_core *core)
 	if (ret)
 		goto error_unload_fw;
 
+	ret = iris_vpu_switch_to_hwmode(core);
+	if (ret)
+		goto error_unload_fw;
+
 	ret = iris_hfi_core_init(core);
 	if (ret)
 		goto error_unload_fw;
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.c b/drivers/media/platform/qcom/iris/iris_hfi_common.c
index 92112eb16c11048e28230a2926dfb46e3163aada..621c66593d88d47ef3438c98a07cb29421c4e375 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_common.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_common.c
@@ -159,6 +159,10 @@ int iris_hfi_pm_resume(struct iris_core *core)
 	if (ret)
 		goto err_suspend_hw;
 
+	ret = iris_vpu_switch_to_hwmode(core);
+	if (ret)
+		goto err_suspend_hw;
+
 	ret = ops->sys_interframe_powercollapse(core);
 	if (ret)
 		goto err_suspend_hw;
diff --git a/drivers/media/platform/qcom/iris/iris_vpu2.c b/drivers/media/platform/qcom/iris/iris_vpu2.c
index 9c103a2e4e4eafee101a8a9b168fdc8ca76e277d..01ef40f3895743b3784464e2d5ba2de1aeca5a4a 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu2.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu2.c
@@ -44,4 +44,5 @@ const struct vpu_ops iris_vpu2_ops = {
 	.power_off_controller = iris_vpu_power_off_controller,
 	.power_on_controller = iris_vpu_power_on_controller,
 	.calc_freq = iris_vpu2_calc_freq,
+	.set_hwmode = iris_vpu_set_hwmode,
 };
diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
index fe4423b951b1e9e31d06dffc69d18071cc985731..3dad47be78b58f6cd5ed6f333b3376571a04dbf0 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
@@ -234,14 +234,8 @@ static int iris_vpu35_power_on_hw(struct iris_core *core)
 	if (ret)
 		goto err_disable_hw_free_clk;
 
-	ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
-	if (ret)
-		goto err_disable_hw_clk;
-
 	return 0;
 
-err_disable_hw_clk:
-	iris_disable_unprepare_clock(core, IRIS_HW_CLK);
 err_disable_hw_free_clk:
 	iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
 err_disable_axi_clk:
@@ -266,6 +260,7 @@ const struct vpu_ops iris_vpu3_ops = {
 	.power_off_controller = iris_vpu_power_off_controller,
 	.power_on_controller = iris_vpu_power_on_controller,
 	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
+	.set_hwmode = iris_vpu_set_hwmode,
 };
 
 const struct vpu_ops iris_vpu33_ops = {
@@ -274,6 +269,7 @@ const struct vpu_ops iris_vpu33_ops = {
 	.power_off_controller = iris_vpu33_power_off_controller,
 	.power_on_controller = iris_vpu_power_on_controller,
 	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
+	.set_hwmode = iris_vpu_set_hwmode,
 };
 
 const struct vpu_ops iris_vpu35_ops = {
@@ -283,4 +279,5 @@ const struct vpu_ops iris_vpu35_ops = {
 	.power_on_controller = iris_vpu35_vpu4x_power_on_controller,
 	.program_bootup_registers = iris_vpu35_vpu4x_program_bootup_registers,
 	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
+	.set_hwmode = iris_vpu_set_hwmode,
 };
diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/media/platform/qcom/iris/iris_vpu4x.c
index a8db02ce5c5ec583c4027166b34ce51d3d683b4e..02e100a4045fced33d7a3545b632cc5f0955233f 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu4x.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
@@ -252,21 +252,10 @@ static int iris_vpu4x_power_on_hardware(struct iris_core *core)
 		ret = iris_vpu4x_power_on_apv(core);
 		if (ret)
 			goto disable_hw_clocks;
-
-		iris_vpu4x_ahb_sync_reset_apv(core);
 	}
 
-	iris_vpu4x_ahb_sync_reset_hardware(core);
-
-	ret = iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
-	if (ret)
-		goto disable_apv_power_domain;
-
 	return 0;
 
-disable_apv_power_domain:
-	if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
-		iris_vpu4x_power_off_apv(core);
 disable_hw_clocks:
 	iris_vpu4x_disable_hardware_clocks(core, efuse_value);
 disable_vpp1_power_domain:
@@ -359,6 +348,18 @@ static void iris_vpu4x_power_off_hardware(struct iris_core *core)
 	iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
 }
 
+static int iris_vpu4x_set_hwmode(struct iris_core *core)
+{
+	u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
+
+	if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
+		iris_vpu4x_ahb_sync_reset_apv(core);
+
+	iris_vpu4x_ahb_sync_reset_hardware(core);
+
+	return iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
+}
+
 const struct vpu_ops iris_vpu4x_ops = {
 	.power_off_hw = iris_vpu4x_power_off_hardware,
 	.power_on_hw = iris_vpu4x_power_on_hardware,
@@ -366,4 +367,5 @@ const struct vpu_ops iris_vpu4x_ops = {
 	.power_on_controller = iris_vpu35_vpu4x_power_on_controller,
 	.program_bootup_registers = iris_vpu35_vpu4x_program_bootup_registers,
 	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
+	.set_hwmode = iris_vpu4x_set_hwmode,
 };
diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
index 548e5f1727fdb7543f76a1871f17257fa2360733..69e6126dc4d95ed9e5fccf596205e84ec0bfc82d 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
+++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
@@ -292,14 +292,8 @@ int iris_vpu_power_on_hw(struct iris_core *core)
 	if (ret && ret != -ENOENT)
 		goto err_disable_hw_clock;
 
-	ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
-	if (ret)
-		goto err_disable_hw_ahb_clock;
-
 	return 0;
 
-err_disable_hw_ahb_clock:
-	iris_disable_unprepare_clock(core, IRIS_HW_AHB_CLK);
 err_disable_hw_clock:
 	iris_disable_unprepare_clock(core, IRIS_HW_CLK);
 err_disable_power:
@@ -308,6 +302,16 @@ int iris_vpu_power_on_hw(struct iris_core *core)
 	return ret;
 }
 
+int iris_vpu_set_hwmode(struct iris_core *core)
+{
+	return dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
+}
+
+int iris_vpu_switch_to_hwmode(struct iris_core *core)
+{
+	return core->iris_platform_data->vpu_ops->set_hwmode(core);
+}
+
 int iris_vpu35_vpu4x_power_off_controller(struct iris_core *core)
 {
 	u32 clk_rst_tbl_size = core->iris_platform_data->clk_rst_tbl_size;
diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.h b/drivers/media/platform/qcom/iris/iris_vpu_common.h
index f6dffc613b822341fb21e12de6b1395202f62cde..dee3b1349c5e869619c7f7c294dd711f9ff72b92 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu_common.h
+++ b/drivers/media/platform/qcom/iris/iris_vpu_common.h
@@ -21,6 +21,7 @@ struct vpu_ops {
 	int (*power_on_controller)(struct iris_core *core);
 	void (*program_bootup_registers)(struct iris_core *core);
 	u64 (*calc_freq)(struct iris_inst *inst, size_t data_size);
+	int (*set_hwmode)(struct iris_core *core);
 };
 
 int iris_vpu_boot_firmware(struct iris_core *core);
@@ -30,6 +31,8 @@ int iris_vpu_watchdog(struct iris_core *core, u32 intr_status);
 int iris_vpu_prepare_pc(struct iris_core *core);
 int iris_vpu_power_on_controller(struct iris_core *core);
 int iris_vpu_power_on_hw(struct iris_core *core);
+int iris_vpu_set_hwmode(struct iris_core *core);
+int iris_vpu_switch_to_hwmode(struct iris_core *core);
 int iris_vpu_power_on(struct iris_core *core);
 int iris_vpu_power_off_controller(struct iris_core *core);
 void iris_vpu_power_off_hw(struct iris_core *core);

-- 
2.34.1

[PATCH 5/7] media: iris: add context bank devices using iommu-map

[Vikash Garodia]

Introduce different context banks(CB) and the associated buffer region.
Different stream IDs from VPU would be associated to one of these CB.
The patch ensures to handle CBs which are described as iommu-map in DT.
Multiple CBs are needed to increase the IOVA for the video usecases like
higher concurrent sessions.

Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 .../platform/qcom/iris/iris_platform_common.h      | 29 ++++++++++++
 drivers/media/platform/qcom/iris/iris_probe.c      | 55 ++++++++++++++++++++--
 drivers/media/platform/qcom/iris/iris_resources.c  | 35 ++++++++++++++
 drivers/media/platform/qcom/iris/iris_resources.h  |  1 +
 4 files changed, 116 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index 5a489917580eb10022fdcb52f7321a915e8b239d..d2d7c898fc8ef0de1b16aebd72681ea3c5b736ae 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -204,6 +204,33 @@ struct icc_vote_data {
 	u32 fps;
 };
 
+enum iris_iommu_map_function_id {
+	IRIS_CB_NON_SECURE_NON_PIXEL	= 0x100,
+	IRIS_CB_NON_SECURE_PIXEL	= 0x101,
+	IRIS_CB_NON_SECURE_BITSTREAM	= 0x102,
+	IRIS_CB_SECURE_NON_PIXEL	= 0x200,
+	IRIS_CB_SECURE_PIXEL		= 0x201,
+	IRIS_CB_SECURE_BITSTREAM	= 0x202,
+	IRIS_CB_FIRMWARE		= 0x300,
+};
+
+enum iris_buffer_region {
+	IRIS_NON_SECURE_NON_PIXEL	= BIT(0),
+	IRIS_NON_SECURE_PIXEL		= BIT(1),
+	IRIS_NON_SECURE_BITSTREAM	= BIT(2),
+	IRIS_SECURE_NON_PIXEL		= BIT(3),
+	IRIS_SECURE_PIXEL		= BIT(4),
+	IRIS_SECURE_BITSTREAM		= BIT(5),
+};
+
+struct iris_context_bank {
+	struct device *dev;
+	const char *name;
+	const enum iris_iommu_map_function_id f_id;
+	const enum iris_buffer_region region;
+	const u64 dma_mask;
+};
+
 enum platform_pm_domain_type {
 	IRIS_CTRL_POWER_DOMAIN,
 	IRIS_HW_POWER_DOMAIN,
@@ -246,6 +273,8 @@ struct iris_platform_data {
 	u32 inst_fw_caps_enc_size;
 	const struct tz_cp_config *tz_cp_config_data;
 	u32 tz_cp_config_data_size;
+	struct iris_context_bank *cb_data;
+	u32 cb_data_size;
 	u32 core_arch;
 	u32 hw_response_timeout;
 	struct ubwc_config_data *ubwc_config;
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index ddaacda523ecb9990af0dd0640196223fbcc2cab..c1a6aac5a3d65d980c5a34ba5fa1c1dbcf790ec5 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -123,6 +123,37 @@ static int iris_init_resets(struct iris_core *core)
 				     core->iris_platform_data->controller_rst_tbl_size);
 }
 
+static int iris_init_context_bank_devices(struct iris_core *core)
+{
+	struct iris_context_bank *cb;
+	const __be32 *map_data;
+	int tupple_size = 5;
+	int i, j, ret, len;
+	u32 fid;
+
+	map_data = of_get_property(core->dev->of_node, "iommu-map", &len);
+	if (!map_data)
+		return 0;
+
+	len /= sizeof(__be32);
+
+	for (i = 0; i < len; i += tupple_size) {
+		fid = be32_to_cpu(map_data[i]);
+
+		for (j = 0; j < core->iris_platform_data->cb_data_size; j++) {
+			cb = &core->iris_platform_data->cb_data[j];
+
+			if (fid == cb->f_id && !cb->dev) {
+				ret = iris_create_child_device_and_map(core, cb);
+				if (ret)
+					return ret;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static int iris_init_resources(struct iris_core *core)
 {
 	int ret;
@@ -139,7 +170,11 @@ static int iris_init_resources(struct iris_core *core)
 	if (ret)
 		return ret;
 
-	return iris_init_resets(core);
+	ret = iris_init_resets(core);
+	if (ret)
+		return ret;
+
+	return iris_init_context_bank_devices(core);
 }
 
 static int iris_register_video_device(struct iris_core *core, enum domain_type type)
@@ -187,6 +222,8 @@ static int iris_register_video_device(struct iris_core *core, enum domain_type t
 static void iris_remove(struct platform_device *pdev)
 {
 	struct iris_core *core;
+	struct device *dev;
+	int i;
 
 	core = platform_get_drvdata(pdev);
 	if (!core)
@@ -194,6 +231,14 @@ static void iris_remove(struct platform_device *pdev)
 
 	iris_core_deinit(core);
 
+	for (i = 0; i < core->iris_platform_data->cb_data_size; i++) {
+		dev = core->iris_platform_data->cb_data[i].dev;
+		if (dev) {
+			platform_device_unregister(to_platform_device(dev));
+			core->iris_platform_data->cb_data[i].dev = NULL;
+		}
+	}
+
 	video_unregister_device(core->vdev_dec);
 	video_unregister_device(core->vdev_enc);
 
@@ -277,9 +322,11 @@ static int iris_probe(struct platform_device *pdev)
 
 	dma_mask = core->iris_platform_data->dma_mask;
 
-	ret = dma_set_mask_and_coherent(dev, dma_mask);
-	if (ret)
-		goto err_vdev_unreg_enc;
+	if (device_iommu_mapped(core->dev)) {
+		ret = dma_set_mask_and_coherent(core->dev, dma_mask);
+		if (ret)
+			goto err_vdev_unreg_enc;
+	}
 
 	dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
 	dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
index 773f6548370a257b8ae7332242544266cbbd61a9..647f6760f2b7a6bab8a585a13eb03cf60a9c047e 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -6,6 +6,7 @@
 #include <linux/clk.h>
 #include <linux/devfreq.h>
 #include <linux/interconnect.h>
+#include <linux/of_device.h>
 #include <linux/pm_domain.h>
 #include <linux/pm_opp.h>
 #include <linux/pm_runtime.h>
@@ -141,3 +142,37 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
 
 	return 0;
 }
+
+int iris_create_child_device_and_map(struct iris_core *core, struct iris_context_bank *cb)
+{
+	struct platform_device *pdev;
+	int ret;
+
+	pdev = platform_device_alloc(cb->name, 0);
+	if (!pdev)
+		return -ENOMEM;
+
+	ret = platform_device_add(pdev);
+	if (ret) {
+		platform_device_put(pdev);
+		return ret;
+	}
+
+	ret = of_dma_configure_id(&pdev->dev, core->dev->of_node, true,
+				  (const u32 *)&cb->f_id);
+	if (ret)
+		goto error_unregister;
+
+	ret = dma_set_mask_and_coherent(&pdev->dev, cb->dma_mask);
+	if (ret)
+		goto error_unregister;
+
+	cb->dev = &pdev->dev;
+
+	return 0;
+
+error_unregister:
+	platform_device_unregister(to_platform_device(&pdev->dev));
+
+	return ret;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index 6bfbd2dc6db095ec05e53c894e048285f82446c6..b7efe15facb203eea9ae13d5f0abdcc2ea718b4d 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.h
+++ b/drivers/media/platform/qcom/iris/iris_resources.h
@@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
 int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
 int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
 int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
+int iris_create_child_device_and_map(struct iris_core *core, struct iris_context_bank *cb);
 
 #endif

-- 
2.34.1

[PATCH 6/7] media: iris: add helper to select context bank device

[Vikash Garodia]

Depending on the buffer type (input, output, internal and interface
queues), associated context bank is selected, if available. Fallback to
parent device for backward compatibility.

Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 drivers/media/platform/qcom/iris/iris_buffer.c    |  7 +--
 drivers/media/platform/qcom/iris/iris_buffer.h    |  2 +
 drivers/media/platform/qcom/iris/iris_hfi_queue.c | 16 ++++---
 drivers/media/platform/qcom/iris/iris_resources.c | 58 +++++++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_resources.h |  2 +
 drivers/media/platform/qcom/iris/iris_vidc.c      |  4 +-
 6 files changed, 77 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
index f1f003a787bf22db6f048c9e682ba8ed2f39bc21..060b12525a63b9dbffa19f23c63f1dc50429069b 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_buffer.c
@@ -335,8 +335,8 @@ void iris_get_internal_buffers(struct iris_inst *inst, u32 plane)
 static int iris_create_internal_buffer(struct iris_inst *inst,
 				       enum iris_buffer_type buffer_type, u32 index)
 {
+	struct device *dev = iris_get_cb_dev(inst->core, inst, buffer_type);
 	struct iris_buffers *buffers = &inst->buffers[buffer_type];
-	struct iris_core *core = inst->core;
 	struct iris_buffer *buffer;
 
 	if (!buffers->size)
@@ -352,7 +352,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
 	buffer->buffer_size = buffers->size;
 	buffer->dma_attrs = DMA_ATTR_WRITE_COMBINE | DMA_ATTR_NO_KERNEL_MAPPING;
 
-	buffer->kvaddr = dma_alloc_attrs(core->dev, buffer->buffer_size,
+	buffer->kvaddr = dma_alloc_attrs(dev, buffer->buffer_size,
 					 &buffer->device_addr, GFP_KERNEL, buffer->dma_attrs);
 	if (!buffer->kvaddr) {
 		kfree(buffer);
@@ -490,9 +490,10 @@ int iris_queue_internal_buffers(struct iris_inst *inst, u32 plane)
 int iris_destroy_internal_buffer(struct iris_inst *inst, struct iris_buffer *buffer)
 {
 	struct iris_core *core = inst->core;
+	struct device *dev = iris_get_cb_dev(core, inst, buffer->type);
 
 	list_del(&buffer->list);
-	dma_free_attrs(core->dev, buffer->buffer_size, buffer->kvaddr,
+	dma_free_attrs(dev, buffer->buffer_size, buffer->kvaddr,
 		       buffer->device_addr, buffer->dma_attrs);
 	kfree(buffer);
 
diff --git a/drivers/media/platform/qcom/iris/iris_buffer.h b/drivers/media/platform/qcom/iris/iris_buffer.h
index 75bb767761824c4c02e0df9b765896cc093be333..9520aa290b44f06ed2004ad89940c19d1c08a3d2 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.h
+++ b/drivers/media/platform/qcom/iris/iris_buffer.h
@@ -28,6 +28,7 @@ struct iris_inst;
  * @BUF_SCRATCH_2: buffer to store encoding context data for HW
  * @BUF_VPSS: buffer to store VPSS context data for HW
  * @BUF_PARTIAL: buffer for AV1 IBC data
+ * @BUF_HFI_QUEUE: buffer for hardware firmware interface queue
  * @BUF_TYPE_MAX: max buffer types
  */
 enum iris_buffer_type {
@@ -44,6 +45,7 @@ enum iris_buffer_type {
 	BUF_SCRATCH_2,
 	BUF_VPSS,
 	BUF_PARTIAL,
+	BUF_HFI_QUEUE,
 	BUF_TYPE_MAX,
 };
 
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_queue.c b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
index b3ed06297953b902d5ea6c452385a88d5431ac66..c1241fb8dc6519020a063cbba87aed665701d7ae 100644
--- a/drivers/media/platform/qcom/iris/iris_hfi_queue.c
+++ b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
@@ -245,25 +245,26 @@ static void iris_hfi_queue_deinit(struct iris_iface_q_info *iface_q)
 
 int iris_hfi_queues_init(struct iris_core *core)
 {
+	struct device *dev = iris_get_cb_dev(core, NULL, BUF_HFI_QUEUE);
 	struct iris_hfi_queue_table_header *q_tbl_hdr;
 	u32 queue_size;
 
 	/* Iris hardware requires 4K queue alignment */
 	queue_size = ALIGN((sizeof(*q_tbl_hdr) + (IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ)), SZ_4K);
-	core->iface_q_table_vaddr = dma_alloc_attrs(core->dev, queue_size,
+	core->iface_q_table_vaddr = dma_alloc_attrs(dev, queue_size,
 						    &core->iface_q_table_daddr,
 						    GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
 	if (!core->iface_q_table_vaddr) {
-		dev_err(core->dev, "queues alloc and map failed\n");
+		dev_err(dev, "queues alloc and map failed\n");
 		return -ENOMEM;
 	}
 
-	core->sfr_vaddr = dma_alloc_attrs(core->dev, SFR_SIZE,
+	core->sfr_vaddr = dma_alloc_attrs(dev, SFR_SIZE,
 					  &core->sfr_daddr,
 					  GFP_KERNEL, DMA_ATTR_WRITE_COMBINE);
 	if (!core->sfr_vaddr) {
-		dev_err(core->dev, "sfr alloc and map failed\n");
-		dma_free_attrs(core->dev, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
+		dev_err(dev, "sfr alloc and map failed\n");
+		dma_free_attrs(dev, sizeof(*q_tbl_hdr), core->iface_q_table_vaddr,
 			       core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
 		return -ENOMEM;
 	}
@@ -291,6 +292,7 @@ int iris_hfi_queues_init(struct iris_core *core)
 
 void iris_hfi_queues_deinit(struct iris_core *core)
 {
+	struct device *dev = iris_get_cb_dev(core, NULL, BUF_HFI_QUEUE);
 	u32 queue_size;
 
 	if (!core->iface_q_table_vaddr)
@@ -300,7 +302,7 @@ void iris_hfi_queues_deinit(struct iris_core *core)
 	iris_hfi_queue_deinit(&core->message_queue);
 	iris_hfi_queue_deinit(&core->command_queue);
 
-	dma_free_attrs(core->dev, SFR_SIZE, core->sfr_vaddr,
+	dma_free_attrs(dev, SFR_SIZE, core->sfr_vaddr,
 		       core->sfr_daddr, DMA_ATTR_WRITE_COMBINE);
 
 	core->sfr_vaddr = NULL;
@@ -309,7 +311,7 @@ void iris_hfi_queues_deinit(struct iris_core *core)
 	queue_size = ALIGN(sizeof(struct iris_hfi_queue_table_header) +
 		(IFACEQ_QUEUE_SIZE * IFACEQ_NUMQ), SZ_4K);
 
-	dma_free_attrs(core->dev, queue_size, core->iface_q_table_vaddr,
+	dma_free_attrs(dev, queue_size, core->iface_q_table_vaddr,
 		       core->iface_q_table_daddr, DMA_ATTR_WRITE_COMBINE);
 
 	core->iface_q_table_vaddr = NULL;
diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
index 647f6760f2b7a6bab8a585a13eb03cf60a9c047e..dd3577cf485ac238015f919f663198a575e78dde 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -13,6 +13,7 @@
 #include <linux/reset.h>
 
 #include "iris_core.h"
+#include "iris_instance.h"
 #include "iris_resources.h"
 
 #define BW_THRESHOLD 50000
@@ -176,3 +177,60 @@ int iris_create_child_device_and_map(struct iris_core *core, struct iris_context
 
 	return ret;
 }
+
+static enum iris_buffer_region iris_get_region(struct iris_inst *inst,
+					       enum iris_buffer_type buffer_type)
+{
+	switch (buffer_type) {
+	case BUF_INPUT:
+		if (inst && inst->domain == ENCODER)
+			return IRIS_NON_SECURE_PIXEL;
+		else if (inst && inst->domain == DECODER)
+			return IRIS_NON_SECURE_BITSTREAM;
+		break;
+	case BUF_OUTPUT:
+		if (inst && inst->domain == ENCODER)
+			return IRIS_NON_SECURE_BITSTREAM;
+		else if (inst && inst->domain == DECODER)
+			return IRIS_NON_SECURE_PIXEL;
+		break;
+	case BUF_DPB:
+	case BUF_VPSS:
+	case BUF_SCRATCH_2:
+		return IRIS_NON_SECURE_PIXEL;
+	case BUF_BIN:
+	case BUF_COMV:
+	case BUF_NON_COMV:
+	case BUF_LINE:
+	case BUF_PERSIST:
+	case BUF_ARP:
+	case BUF_HFI_QUEUE:
+		return IRIS_NON_SECURE_NON_PIXEL;
+	default:
+		return 0;
+	}
+
+	return 0;
+}
+
+struct device *iris_get_cb_dev(struct iris_core *core, struct iris_inst *inst,
+			       enum iris_buffer_type buffer_type)
+{
+	enum iris_buffer_region region;
+	struct device *dev = NULL;
+	int i;
+
+	region = iris_get_region(inst, buffer_type);
+
+	for (i = 0; i < core->iris_platform_data->cb_data_size; i++) {
+		if (core->iris_platform_data->cb_data[i].region & region) {
+			dev = core->iris_platform_data->cb_data[i].dev;
+			break;
+		}
+	}
+
+	if (!dev)
+		dev = core->dev;
+
+	return dev;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index b7efe15facb203eea9ae13d5f0abdcc2ea718b4d..ea31726f1789130fccf6b24540a62b86cb3c36ac 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.h
+++ b/drivers/media/platform/qcom/iris/iris_resources.h
@@ -16,5 +16,7 @@ int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
 int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
 int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
 int iris_create_child_device_and_map(struct iris_core *core, struct iris_context_bank *cb);
+struct device *iris_get_cb_dev(struct iris_core *core, struct iris_inst *inst,
+			       enum iris_buffer_type buffer_type);
 
 #endif
diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
index bd38d84c9cc79d15585ed5dd5f905a37521cb6dc..b61d7941d88662f34a9d2ab3b6c5bd9acf4b5df5 100644
--- a/drivers/media/platform/qcom/iris/iris_vidc.c
+++ b/drivers/media/platform/qcom/iris/iris_vidc.c
@@ -107,7 +107,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
 	src_vq->drv_priv = inst;
 	src_vq->buf_struct_size = sizeof(struct iris_buffer);
 	src_vq->min_reqbufs_allocation = MIN_BUFFERS;
-	src_vq->dev = inst->core->dev;
+	src_vq->dev = iris_get_cb_dev(inst->core, inst, BUF_INPUT);
 	src_vq->lock = &inst->ctx_q_lock;
 	ret = vb2_queue_init(src_vq);
 	if (ret)
@@ -121,7 +121,7 @@ iris_m2m_queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_
 	dst_vq->drv_priv = inst;
 	dst_vq->buf_struct_size = sizeof(struct iris_buffer);
 	dst_vq->min_reqbufs_allocation = MIN_BUFFERS;
-	dst_vq->dev = inst->core->dev;
+	dst_vq->dev = iris_get_cb_dev(inst->core, inst, BUF_OUTPUT);
 	dst_vq->lock = &inst->ctx_q_lock;
 
 	return vb2_queue_init(dst_vq);

-- 
2.34.1

[PATCH 7/7] media: iris: Add platform data for kaanapali

[Vikash Garodia]

Add support for the kaanapali platform by re-using the SM8550
definitions and using the vpu4 ops.
Move the configurations that differs in a per-SoC platform
header, that will contain SoC specific data.

Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 .../platform/qcom/iris/iris_platform_common.h      |  1 +
 .../media/platform/qcom/iris/iris_platform_gen2.c  | 90 ++++++++++++++++++++++
 .../platform/qcom/iris/iris_platform_kaanapali.h   | 80 +++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  4 +
 4 files changed, 175 insertions(+)

diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index d2d7c898fc8ef0de1b16aebd72681ea3c5b736ae..3f047bd495413494b9afbf6f4d12a8e06a9ac07a 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -41,6 +41,7 @@ enum pipe_type {
 	PIPE_4 = 4,
 };
 
+extern const struct iris_platform_data kaanapali_data;
 extern const struct iris_platform_data qcs8300_data;
 extern const struct iris_platform_data sc7280_data;
 extern const struct iris_platform_data sm8250_data;
diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
index 5da90d47f9c6eab4a7e6b17841fdc0e599397bf7..cefbe72b1475cb83281d01ef3828f095293e098f 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
@@ -12,6 +12,7 @@
 #include "iris_vpu_buffer.h"
 #include "iris_vpu_common.h"
 
+#include "iris_platform_kaanapali.h"
 #include "iris_platform_qcs8300.h"
 #include "iris_platform_sm8650.h"
 #include "iris_platform_sm8750.h"
@@ -921,6 +922,95 @@ static const u32 sm8550_enc_op_int_buf_tbl[] = {
 	BUF_SCRATCH_2,
 };
 
+const struct iris_platform_data kaanapali_data = {
+	.get_instance = iris_hfi_gen2_get_instance,
+	.init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
+	.init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
+	.get_vpu_buffer_size = iris_vpu4x_buf_size,
+	.vpu_ops = &iris_vpu4x_ops,
+	.set_preset_registers = iris_set_sm8550_preset_registers,
+	.icc_tbl = sm8550_icc_table,
+	.icc_tbl_size = ARRAY_SIZE(sm8550_icc_table),
+	.clk_rst_tbl = kaanapali_clk_reset_table,
+	.clk_rst_tbl_size = ARRAY_SIZE(kaanapali_clk_reset_table),
+	.bw_tbl_dec = sm8550_bw_table_dec,
+	.bw_tbl_dec_size = ARRAY_SIZE(sm8550_bw_table_dec),
+	.pmdomain_tbl = kaanapali_pmdomain_table,
+	.pmdomain_tbl_size = ARRAY_SIZE(kaanapali_pmdomain_table),
+	.opp_pd_tbl = sm8550_opp_pd_table,
+	.opp_pd_tbl_size = ARRAY_SIZE(sm8550_opp_pd_table),
+	.clk_tbl = kaanapali_clk_table,
+	.clk_tbl_size = ARRAY_SIZE(kaanapali_clk_table),
+	.opp_clk_tbl = kaanapali_opp_clk_table,
+	/* Upper bound of DMA address range */
+	.dma_mask = 0xffe00000 - 1,
+	.fwname = "qcom/vpu/vpu40_p2_s7.mbn",
+	.pas_id = IRIS_PAS_ID,
+	.inst_iris_fmts = platform_fmts_sm8550_dec,
+	.inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sm8550_dec),
+	.inst_caps = &platform_inst_cap_sm8550,
+	.inst_fw_caps_dec = inst_fw_cap_sm8550_dec,
+	.inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8550_dec),
+	.inst_fw_caps_enc = inst_fw_cap_sm8550_enc,
+	.inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_sm8550_enc),
+	.tz_cp_config_data = tz_cp_config_kaanapali,
+	.tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_kaanapali),
+	.cb_data = kaanapali_cb_data,
+	.cb_data_size = ARRAY_SIZE(kaanapali_cb_data),
+	.core_arch = VIDEO_ARCH_LX,
+	.hw_response_timeout = HW_RESPONSE_TIMEOUT_VALUE,
+	.ubwc_config = &ubwc_config_sm8550,
+	.num_vpp_pipe = 2,
+	.max_session_count = 16,
+	.max_core_mbpf = NUM_MBS_8K * 2,
+	.max_core_mbps = ((8192 * 4352) / 256) * 60,
+	.dec_input_config_params_default =
+		sm8550_vdec_input_config_params_default,
+	.dec_input_config_params_default_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_params_default),
+	.dec_input_config_params_hevc =
+		sm8550_vdec_input_config_param_hevc,
+	.dec_input_config_params_hevc_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_param_hevc),
+	.dec_input_config_params_vp9 =
+		sm8550_vdec_input_config_param_vp9,
+	.dec_input_config_params_vp9_size =
+		ARRAY_SIZE(sm8550_vdec_input_config_param_vp9),
+	.dec_output_config_params =
+		sm8550_vdec_output_config_params,
+	.dec_output_config_params_size =
+		ARRAY_SIZE(sm8550_vdec_output_config_params),
+
+	.enc_input_config_params =
+		sm8550_venc_input_config_params,
+	.enc_input_config_params_size =
+		ARRAY_SIZE(sm8550_venc_input_config_params),
+	.enc_output_config_params =
+		sm8550_venc_output_config_params,
+	.enc_output_config_params_size =
+		ARRAY_SIZE(sm8550_venc_output_config_params),
+
+	.dec_input_prop = sm8550_vdec_subscribe_input_properties,
+	.dec_input_prop_size = ARRAY_SIZE(sm8550_vdec_subscribe_input_properties),
+	.dec_output_prop_avc = sm8550_vdec_subscribe_output_properties_avc,
+	.dec_output_prop_avc_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_avc),
+	.dec_output_prop_hevc = sm8550_vdec_subscribe_output_properties_hevc,
+	.dec_output_prop_hevc_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_hevc),
+	.dec_output_prop_vp9 = sm8550_vdec_subscribe_output_properties_vp9,
+	.dec_output_prop_vp9_size =
+		ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_vp9),
+
+	.dec_ip_int_buf_tbl = sm8550_dec_ip_int_buf_tbl,
+	.dec_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_ip_int_buf_tbl),
+	.dec_op_int_buf_tbl = sm8550_dec_op_int_buf_tbl,
+	.dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_op_int_buf_tbl),
+
+	.enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
+	.enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
+};
+
 const struct iris_platform_data sm8550_data = {
 	.get_instance = iris_hfi_gen2_get_instance,
 	.init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
diff --git a/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
new file mode 100644
index 0000000000000000000000000000000000000000..d472e21fdac4c764169a3a8c35d175db29b06b5b
--- /dev/null
+++ b/drivers/media/platform/qcom/iris/iris_platform_kaanapali.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef __IRIS_PLATFORM_KAANAPALI_H__
+#define __IRIS_PLATFORM_KAANAPALI_H__
+
+#define VIDEO_REGION_VM0_SECURE_NP_ID		1
+#define VIDEO_REGION_VM0_NONSECURE_NP_ID	5
+
+static const char *const kaanapali_clk_reset_table[] = {
+	"bus0",
+	"bus1",
+	"core",
+	"vcodec0_core",
+};
+
+static const char *const kaanapali_pmdomain_table[] = {
+	"venus",
+	"vcodec0",
+	"vpp0",
+	"vpp1",
+	"apv",
+};
+
+static const struct platform_clk_data kaanapali_clk_table[] = {
+	{ IRIS_AXI_CLK, "iface" },
+	{ IRIS_CTRL_CLK, "core" },
+	{ IRIS_HW_CLK, "vcodec0_core" },
+	{ IRIS_AXI1_CLK, "iface1" },
+	{ IRIS_CTRL_FREERUN_CLK, "core_freerun" },
+	{ IRIS_HW_FREERUN_CLK, "vcodec0_core_freerun" },
+	{ IRIS_BSE_HW_CLK, "vcodec_bse" },
+	{ IRIS_VPP0_HW_CLK, "vcodec_vpp0" },
+	{ IRIS_VPP1_HW_CLK, "vcodec_vpp1" },
+	{ IRIS_APV_HW_CLK, "vcodec_apv" },
+};
+
+static const char *const kaanapali_opp_clk_table[] = {
+	"vcodec0_core",
+	"vcodec_apv",
+	"vcodec_bse",
+	"core",
+	NULL,
+};
+
+static struct tz_cp_config tz_cp_config_kaanapali[] = {
+	{
+		.cp_start = VIDEO_REGION_VM0_SECURE_NP_ID,
+		.cp_size = 0,
+		.cp_nonpixel_start = 0x01000000,
+		.cp_nonpixel_size = 0x24800000,
+	},
+	{
+		.cp_start = VIDEO_REGION_VM0_NONSECURE_NP_ID,
+		.cp_size = 0,
+		.cp_nonpixel_start = 0x25800000,
+		.cp_nonpixel_size = 0xda400000,
+	},
+};
+
+static struct iris_context_bank kaanapali_cb_data[] = {
+	{
+		.dev = NULL,
+		.name = "iris_cb_non_pixel",
+		.f_id = IRIS_CB_NON_SECURE_NON_PIXEL,
+		.region = IRIS_NON_SECURE_NON_PIXEL | IRIS_NON_SECURE_BITSTREAM,
+		.dma_mask = 0xffe00000 - 1,
+	},
+	{
+		.dev = NULL,
+		.name = "iris_cb_pixel",
+		.f_id = IRIS_CB_NON_SECURE_PIXEL,
+		.region = IRIS_NON_SECURE_PIXEL,
+		.dma_mask = 0xffe00000 - 1,
+	},
+};
+
+#endif /* __IRIS_PLATFORM_KAANAPALI_H__ */
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index c1a6aac5a3d65d980c5a34ba5fa1c1dbcf790ec5..9cc55f5e7be1701a14eedd06453ddb0b59844ffa 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -395,6 +395,10 @@ static const struct dev_pm_ops iris_pm_ops = {
 };
 
 static const struct of_device_id iris_dt_match[] = {
+	{
+		.compatible = "qcom,kaanapali-iris",
+		.data = &kaanapali_data,
+	},
 	{
 		.compatible = "qcom,qcs8300-iris",
 		.data = &qcs8300_data,

-- 
2.34.1

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

[Dmitry Baryshkov]

On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> Qualcomm kaanapali platform have a newer generation of video IP iris4. 
> The hardware have evolved mostly with respect to higher number of power 
> domains as well as multiple clock sources.
> 
> The series extends support for multiple iommu-map entries for the same 
> input id. Considering iris as a client driver, it adds the handling for 
> multiple stream ids from VPU via iommu-map.
> 
> This series is depend on the below series:
> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> 
> Following are the compliance and functional validation reports.

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

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

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

> 
> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> Encoders validated with below commands:
> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> location=<output_file.h264>

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

> 
> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> location=<output_file.hevc>
> 
> ffmpeg test:
> Decoders validated with below commands:
> ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> 
> v4l2-ctl test
> Decoders validated with below commands:
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from=<input_file.h264> --stream-to=<output_file.yuv>
> 
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from=input_file.bit --stream-to=<output_file.yuv>
> 
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from-hdr=input_file.hdr  --stream-mmap
> --stream-to=<output_file.yuv>
> 
> Encoders validated with below commands:
> v4l2-ctl --verbose
> --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
> --set-selection-output
> target=crop,top=0,left=0,width=<width>,height=<height>
> --set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap
> --stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d
> /dev/video1
> v4l2-ctl --verbose
> --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
> --set-selection-output
> target=crop,top=0,left=0,width=<width>,height=<height>
> --set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap
> --stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d
> /dev/video1

-- 
With best wishes
Dmitry

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Rob Herring (Arm)]

On Mon, 26 Jan 2026 17:55:44 +0530, Vikash Garodia wrote:
> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> compared to previous generation, iris3x, it has,
> - separate power domains for stream and pixel processing hardware blocks
>   (bse and vpp).
> - additional power domain for apv codec.
> - power domains for individual pipes (VPPx).
> - different clocks and reset lines.
> 
> iommu-map include all the different stream-ids which can be possibly
> generated by vpu4 hardware.
> 
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>  1 file changed, 234 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:2:3: 4294967295 is greater than the maximum of 65536
	from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:4:0: 4294967295 is greater than the maximum of 65535
	from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:7:3: 4294967295 is greater than the maximum of 65536
	from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:9:0: 4294967295 is greater than the maximum of 65535
	from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,kaanapali-iris.example.dtb: video-codec@2000000 (qcom,kaanapali-iris): iommu-map:11: [1] is too short
	from schema $id: http://devicetree.org/schemas/pci/pci-iommu.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260126-kaanapali-iris-v1-1-e2646246bfc1@oss.qualcomm.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

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

[Vikash Garodia]

On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
>> Qualcomm kaanapali platform have a newer generation of video IP iris4.
>> The hardware have evolved mostly with respect to higher number of power
>> domains as well as multiple clock sources.
>>
>> The series extends support for multiple iommu-map entries for the same
>> input id. Considering iris as a client driver, it adds the handling for
>> multiple stream ids from VPU via iommu-map.
>>
>> This series is depend on the below series:
>> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
>>
>> Following are the compliance and functional validation reports.
> 
> Please validate with fluster too. Having a "knowingly good" command line
> is not a validation. It can't be reproduced by anybody else.
> 

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

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

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

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

>> gstreamer test:
>> Decoders validated with below commands, codec specific:
>> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
>> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> Neither of these commands specify, what exactly was validated. They
> specify that you've validated _some_ videos. It's impossible to even
> reproduce your results, because you don't specify which files you've
> used.
> 

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

>>
>> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
>> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>
>> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
>> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>
>> Encoders validated with below commands:
>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>> location=<output_file.h264>
> 
> At least these should use test sinks in order to be reproducible.

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

Regards,
Vikash

Re: [PATCH 3/7] of/iommu: add multi-map support

[Dmitry Baryshkov]

On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> 
> When multiple mappings are present for an input id, linux matches just
> the first one. There is a usecase[1] where all the mappings are to be
> maintained in parallel for an iommu-map entry of a same input id.

This contradicts the IOMMU idealogy (at least as far as I understood it
fom the maintainers): the device (driver) doesn't control which IOMMUs
are getting used. Instead _all_ defined entries should get used. For
iommu-map it means that if the map defines several entries for a single
function, then all entries should always get mapped.

> 
> Whether multi-map is needed is reported by the callers through the
> callback function passed, which is called for every input id match.
> 
> Since the requirement in the usecase[1] is for platform devices, not
> sure if it is really clean to maintain this decision on the bus type at
> the of_iommu layer or further to be from the respective
> iommu_driver->impl_ops().

This doesn't tell us, why do you want to control, which entries of the
map get used.

> 
> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
> 
> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  drivers/iommu/of_iommu.c | 36 ++++++++++++++++++++++++++++--------
>  drivers/of/base.c        | 38 ++++++++++++++++++++++++++++----------
>  include/linux/of.h       |  6 ++++++
>  3 files changed, 62 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 768eaddf927b0700b2497b08ea21611b1a1b5688..067bb2298973671e1eaf01bb2ea52df3d2a52a44 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -16,6 +16,7 @@
>  #include <linux/pci.h>
>  #include <linux/slab.h>
>  #include <linux/fsl/mc.h>
> +#include <linux/platform_device.h>
>  
>  #include "iommu-priv.h"
>  
> @@ -41,22 +42,41 @@ static int of_iommu_xlate(struct device *dev,
>  	return ret;
>  }
>  
> +/*
> + * Callback to be called from of_map_id(), that tells if
> + * all the mappings for an input id to be maintained in
> + * parallel. Should this decission be from further layers,
> + * iommu_driver->impl_ops?
> + */
> +static int of_iommu_configure_cb(struct of_map_id_arg *arg)
> +{
> +	struct of_phandle_args *iommu_spec = &arg->map_args;
> +	struct device *dev = arg->dev;
> +	int err;
> +
> +	err = of_iommu_xlate(dev, iommu_spec);
> +	of_node_put(iommu_spec->np);
> +
> +	/* !iommu_spec->np may be from the bypassed translations */
> +	if (!err)
> +		err = (!arg->multi_map || !iommu_spec->np) ? 0 : -EAGAIN;
> +
> +	return err;
> +}
> +
>  static int of_iommu_configure_dev_id(struct device_node *master_np,
>  				     struct device *dev,
>  				     const u32 *id)
>  {
>  	struct of_map_id_arg arg = {
>  		.map_args = {},
> +		.cb = of_iommu_configure_cb,
> +		.dev = dev,
> +		/* Should this be pushed to iommu_driver->impl_ops? */
> +		.multi_map = dev_is_platform(dev),
>  	};
> -	int err;
> -
> -	err = of_map_iommu_id(master_np, *id, &arg);
> -	if (err)
> -		return err;
>  
> -	err = of_iommu_xlate(dev, &arg.map_args);
> -	of_node_put(arg.map_args.np);
> -	return err;
> +	return of_map_iommu_id(master_np, *id, &arg);
>  }
>  
>  static int of_iommu_configure_dev(struct device_node *master_np,
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 606bef4f90e7d13bae4f7b0c45acd1755ad89826..a1c3c5954ec7e8eb3753c8fd782a1570f9eb9c17 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2122,14 +2122,21 @@ static bool of_check_bad_map(const __be32 *map, int len)
>  	return true;
>  }
>  
> -static int of_map_id_fill_output(struct of_map_id_arg *arg,
> -				 struct device_node *phandle_node, u32 id_or_offset,
> -				 const __be32 *out_base, u32 cells,
> -				 bool bypass)
> +/*
> + * Fill the id_out and target for the of_map_id() caller. Also
> + * call the callback passed to the of_map_id() as part of the arg
> + * that decides if to continue further search.
> + */
> +static int of_map_id_fill_arg(struct of_map_id_arg *arg,
> +			      struct device_node *phandle_node, u32 id_or_offset,
> +			      const __be32 *out_base, u32 cells,
> +			      bool bypass, bool *multi_id_map)
>  {
> +	int ret;
> +
>  	if (bypass) {
>  		arg->map_args.args[0] = id_or_offset;
> -		return 0;
> +		goto output;
>  	}
>  
>  	if (arg->map_args.np)
> @@ -2145,7 +2152,14 @@ static int of_map_id_fill_output(struct of_map_id_arg *arg,
>  
>  	arg->map_args.args_count = cells;
>  
> -	return 0;
> +output:
> +	/* pass the output for the callback, callers may further decide */
> +	ret =  arg->cb ? arg->cb(arg) : 0;
> +
> +	if (multi_id_map && ret == -EAGAIN)
> +		*multi_id_map = true;
> +
> +	return ret;
>  }
>  
>  /**
> @@ -2179,6 +2193,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>  	int map_bytes, map_len, offset = 0;
>  	bool bad_map = false;
>  	const __be32 *map = NULL;
> +	bool multi_id_map = false;
>  
>  	if (!np || !map_name || !arg)
>  		return -EINVAL;
> @@ -2264,23 +2279,26 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>  		if (masked_id < id_base || id_off >= id_len)
>  			continue;
>  
> -		ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
> +		ret = of_map_id_fill_arg(arg, phandle_node, id_off, out_base,
> +					 cells, false, &multi_id_map);
>  		if (ret == -EAGAIN)
>  			continue;
>  
>  		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
>  			np, map_name, map_mask, id_base, be32_to_cpup(out_base),
>  			id_len, id, id_off + be32_to_cpup(out_base));
> -		return 0;
> +		return ret;
>  	}
>  
> +	if (multi_id_map)
> +		return 0;
> +
>  	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
>  		id, arg->map_args.np  ? arg->map_args.np : NULL);
>  
>  bypass_translation:
>  	/* Bypasses translation */
> -	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
> -
> +	return of_map_id_fill_arg(arg, NULL, id, 0, 0, true, NULL);
>  err_map_len:
>  	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
>  	return -EINVAL;
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 9efa6f93712c6024f05476f9fd39f3294f942ec1..abab73a76682351f5635c1127a6c899917525050 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -25,6 +25,9 @@
>  typedef u32 phandle;
>  typedef u32 ihandle;
>  
> +struct of_map_id_arg;
> +typedef int (*of_map_id_cb)(struct of_map_id_arg *arg);
> +
>  struct property {
>  	char	*name;
>  	int	length;
> @@ -76,6 +79,9 @@ struct of_phandle_args {
>  
>  struct of_map_id_arg {
>  	struct of_phandle_args map_args;
> +	of_map_id_cb cb;
> +	struct device *dev;
> +	bool multi_map;
>  };
>  
>  struct of_phandle_iterator {
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> 
> On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> > > Qualcomm kaanapali platform have a newer generation of video IP iris4.
> > > The hardware have evolved mostly with respect to higher number of power
> > > domains as well as multiple clock sources.
> > > 
> > > The series extends support for multiple iommu-map entries for the same
> > > input id. Considering iris as a client driver, it adds the handling for
> > > multiple stream ids from VPU via iommu-map.
> > > 
> > > This series is depend on the below series:
> > > Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> > > 
> > > Following are the compliance and functional validation reports.
> > 
> > Please validate with fluster too. Having a "knowingly good" command line
> > is not a validation. It can't be reproduced by anybody else.
> > 
> 
> Below is the fluster result on kaanapali (will add in cover letter in next
> revision)

Nice, thanks!

> 
> H264:
> 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.

What about the extension testsuites? Even if they are not supported,
they should not crash or cause the timeouts.

> - 52 test vectors failed due to interlaced clips - not supported

Yet or completely? Does "failed" mean "returned an error" or something
else?

> - 3 test vectors failed due to unsupported bitstream.
> - 2 test vectors failed because SP_SLICE type - not supported by the
>   hardware.
> - 1 test vector failed due to unsupported profile
> 
> H265:
>  129/147 testcases passed while testing JCT-VC-HEVC_V1 with
>  GStreamer-H.265-V4L2-Gst1.0.
>  The failing test case:
>  - 10 testcases failed due to unsupported 10 bit format.

MAIN10? I was actually surprised, Venus driver supported them for the
Iris2 hardware. Is it somethething to be fixed in future?

>  - 4 testcase failed due to unsupported resolution

Can it be fixed?

>  - 2 testcase failed due to CRC mismatch

Which means an error in the testsuite or somewhere on our side?

>  - 2 test fails due to session error (under debug)
>    - PICSIZE_C_Bossen_1
>    - WPP_E_ericsson_MAIN_2
> 
> VP9:
> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>  GStreamer-VP9-V4L2-Gst1.0.
>  The failing test case:
>  - 64 testcases failed due to unsupported resolution

Can it be fixed?

>  - 2 testcases failed due to unsupported format

Hmm?

>  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)

Could you please raise an issue against fluster?

>  - 2 testcase failed due to unsupported resolution after sequence change

Can it be fixed?

>  - 1 testcase failed due to unsupported stream

?

> 
> > > gstreamer test:
> > > Decoders validated with below commands, codec specific:
> > > gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
> > > parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > 
> > Neither of these commands specify, what exactly was validated. They
> > specify that you've validated _some_ videos. It's impossible to even
> > reproduce your results, because you don't specify which files you've
> > used.
> > 
> 
> commands are shared indicating the pipeline used for validation for
> different codec plugins. These are some basic encode and decode commands,
> and shared for reference for anyone to pick input test files of their own.

Thanks, but it would also be helpful if you stated, which filesets were
used for validation. There are enough public filesets for testing video
decoders.

> 
> > > 
> > > gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> > > parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > 
> > > gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> > > parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > 
> > > Encoders validated with below commands:
> > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> > > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> > > capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> > > location=<output_file.h264>
> > 
> > At least these should use test sinks in order to be reproducible.
> 
> it is using filesink in the pipeline to generate the encoded bitstream

I should have been more explicit: test sinks to generate the image.

-- 
With best wishes
Dmitry

Re: [PATCH 3/7] of/iommu: add multi-map support

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 8461 bytes --]

Hi,

Le mardi 27 janvier 2026 à 13:45 +0200, Dmitry Baryshkov a écrit :
> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
> > From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> > 
> > When multiple mappings are present for an input id, linux matches just
> > the first one. There is a usecase[1] where all the mappings are to be
> > maintained in parallel for an iommu-map entry of a same input id.
> 
> This contradicts the IOMMU idealogy (at least as far as I understood it
> fom the maintainers): the device (driver) doesn't control which IOMMUs
> are getting used. Instead _all_ defined entries should get used. For
> iommu-map it means that if the map defines several entries for a single
> function, then all entries should always get mapped.
> 
> > 
> > Whether multi-map is needed is reported by the callers through the
> > callback function passed, which is called for every input id match.
> > 
> > Since the requirement in the usecase[1] is for platform devices, not
> > sure if it is really clean to maintain this decision on the bus type at
> > the of_iommu layer or further to be from the respective
> > iommu_driver->impl_ops().
> 
> This doesn't tell us, why do you want to control, which entries of the
> map get used.
> 
> > 
> > [1]
> > https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/

Since its for an M2M V4L2 device, and its all about having more address space
according to this link, you may want to use a different iommu domain per m2m
instances, rather then per device (what is done implicitly). On top of which, it
will ensure memory isolation between instances, making this driver suitable for
virtualisation. 4Gb per instance (which is also per stream) seems like a lot of
memory to me. But like Dmitry says, there is little clarity in what you are
trying to achieve.

Nicolas

> > 
> > Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> > Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > ---
> >  drivers/iommu/of_iommu.c | 36 ++++++++++++++++++++++++++++--------
> >  drivers/of/base.c        | 38 ++++++++++++++++++++++++++++----------
> >  include/linux/of.h       |  6 ++++++
> >  3 files changed, 62 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index
> > 768eaddf927b0700b2497b08ea21611b1a1b5688..067bb2298973671e1eaf01bb2ea52df3d2
> > a52a44 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/pci.h>
> >  #include <linux/slab.h>
> >  #include <linux/fsl/mc.h>
> > +#include <linux/platform_device.h>
> >  
> >  #include "iommu-priv.h"
> >  
> > @@ -41,22 +42,41 @@ static int of_iommu_xlate(struct device *dev,
> >  	return ret;
> >  }
> >  
> > +/*
> > + * Callback to be called from of_map_id(), that tells if
> > + * all the mappings for an input id to be maintained in
> > + * parallel. Should this decission be from further layers,
> > + * iommu_driver->impl_ops?
> > + */
> > +static int of_iommu_configure_cb(struct of_map_id_arg *arg)
> > +{
> > +	struct of_phandle_args *iommu_spec = &arg->map_args;
> > +	struct device *dev = arg->dev;
> > +	int err;
> > +
> > +	err = of_iommu_xlate(dev, iommu_spec);
> > +	of_node_put(iommu_spec->np);
> > +
> > +	/* !iommu_spec->np may be from the bypassed translations */
> > +	if (!err)
> > +		err = (!arg->multi_map || !iommu_spec->np) ? 0 : -EAGAIN;
> > +
> > +	return err;
> > +}
> > +
> >  static int of_iommu_configure_dev_id(struct device_node *master_np,
> >  				     struct device *dev,
> >  				     const u32 *id)
> >  {
> >  	struct of_map_id_arg arg = {
> >  		.map_args = {},
> > +		.cb = of_iommu_configure_cb,
> > +		.dev = dev,
> > +		/* Should this be pushed to iommu_driver->impl_ops? */
> > +		.multi_map = dev_is_platform(dev),
> >  	};
> > -	int err;
> > -
> > -	err = of_map_iommu_id(master_np, *id, &arg);
> > -	if (err)
> > -		return err;
> >  
> > -	err = of_iommu_xlate(dev, &arg.map_args);
> > -	of_node_put(arg.map_args.np);
> > -	return err;
> > +	return of_map_iommu_id(master_np, *id, &arg);
> >  }
> >  
> >  static int of_iommu_configure_dev(struct device_node *master_np,
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index
> > 606bef4f90e7d13bae4f7b0c45acd1755ad89826..a1c3c5954ec7e8eb3753c8fd782a1570f9
> > eb9c17 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -2122,14 +2122,21 @@ static bool of_check_bad_map(const __be32 *map, int
> > len)
> >  	return true;
> >  }
> >  
> > -static int of_map_id_fill_output(struct of_map_id_arg *arg,
> > -				 struct device_node *phandle_node, u32
> > id_or_offset,
> > -				 const __be32 *out_base, u32 cells,
> > -				 bool bypass)
> > +/*
> > + * Fill the id_out and target for the of_map_id() caller. Also
> > + * call the callback passed to the of_map_id() as part of the arg
> > + * that decides if to continue further search.
> > + */
> > +static int of_map_id_fill_arg(struct of_map_id_arg *arg,
> > +			      struct device_node *phandle_node, u32
> > id_or_offset,
> > +			      const __be32 *out_base, u32 cells,
> > +			      bool bypass, bool *multi_id_map)
> >  {
> > +	int ret;
> > +
> >  	if (bypass) {
> >  		arg->map_args.args[0] = id_or_offset;
> > -		return 0;
> > +		goto output;
> >  	}
> >  
> >  	if (arg->map_args.np)
> > @@ -2145,7 +2152,14 @@ static int of_map_id_fill_output(struct of_map_id_arg
> > *arg,
> >  
> >  	arg->map_args.args_count = cells;
> >  
> > -	return 0;
> > +output:
> > +	/* pass the output for the callback, callers may further decide */
> > +	ret =  arg->cb ? arg->cb(arg) : 0;
> > +
> > +	if (multi_id_map && ret == -EAGAIN)
> > +		*multi_id_map = true;
> > +
> > +	return ret;
> >  }
> >  
> >  /**
> > @@ -2179,6 +2193,7 @@ int of_map_id(const struct device_node *np, u32 id,
> > const char *map_name,
> >  	int map_bytes, map_len, offset = 0;
> >  	bool bad_map = false;
> >  	const __be32 *map = NULL;
> > +	bool multi_id_map = false;
> >  
> >  	if (!np || !map_name || !arg)
> >  		return -EINVAL;
> > @@ -2264,23 +2279,26 @@ int of_map_id(const struct device_node *np, u32 id,
> > const char *map_name,
> >  		if (masked_id < id_base || id_off >= id_len)
> >  			continue;
> >  
> > -		ret = of_map_id_fill_output(arg, phandle_node, id_off,
> > out_base, cells, false);
> > +		ret = of_map_id_fill_arg(arg, phandle_node, id_off,
> > out_base,
> > +					 cells, false, &multi_id_map);
> >  		if (ret == -EAGAIN)
> >  			continue;
> >  
> >  		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-
> > base: %08x, length: %08x, id: %08x -> %08x\n",
> >  			np, map_name, map_mask, id_base,
> > be32_to_cpup(out_base),
> >  			id_len, id, id_off + be32_to_cpup(out_base));
> > -		return 0;
> > +		return ret;
> >  	}
> >  
> > +	if (multi_id_map)
> > +		return 0;
> > +
> >  	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np,
> > map_name,
> >  		id, arg->map_args.np  ? arg->map_args.np : NULL);
> >  
> >  bypass_translation:
> >  	/* Bypasses translation */
> > -	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
> > -
> > +	return of_map_id_fill_arg(arg, NULL, id, 0, 0, true, NULL);
> >  err_map_len:
> >  	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name,
> > map_bytes);
> >  	return -EINVAL;
> > diff --git a/include/linux/of.h b/include/linux/of.h
> > index
> > 9efa6f93712c6024f05476f9fd39f3294f942ec1..abab73a76682351f5635c1127a6c899917
> > 525050 100644
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -25,6 +25,9 @@
> >  typedef u32 phandle;
> >  typedef u32 ihandle;
> >  
> > +struct of_map_id_arg;
> > +typedef int (*of_map_id_cb)(struct of_map_id_arg *arg);
> > +
> >  struct property {
> >  	char	*name;
> >  	int	length;
> > @@ -76,6 +79,9 @@ struct of_phandle_args {
> >  
> >  struct of_map_id_arg {
> >  	struct of_phandle_args map_args;
> > +	of_map_id_cb cb;
> > +	struct device *dev;
> > +	bool multi_map;
> >  };
> >  
> >  struct of_phandle_iterator {
> > 
> > -- 
> > 2.34.1
> > 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 3/7] of/iommu: add multi-map support

[Robin Murphy]

On 2026-01-27 11:45 am, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>
>> When multiple mappings are present for an input id, linux matches just
>> the first one. There is a usecase[1] where all the mappings are to be
>> maintained in parallel for an iommu-map entry of a same input id.
> 
> This contradicts the IOMMU idealogy (at least as far as I understood it
> fom the maintainers): the device (driver) doesn't control which IOMMUs
> are getting used. Instead _all_ defined entries should get used. For
> iommu-map it means that if the map defines several entries for a single
> function, then all entries should always get mapped.

Indeed there is no concept of "multi-map" - if a single input ID 
represents more than one thing then that notion of "input ID" is 
fundamentally wrong. A single *device* may have multiple IDs, as in the 
case of PCI bridge aliasing, but in that case there are multiple things 
to map.

Thanks,
Robin.

Re: [PATCH 5/7] media: iris: add context bank devices using iommu-map

[Robin Murphy]

On 2026-01-26 12:25 pm, Vikash Garodia wrote:
> Introduce different context banks(CB) and the associated buffer region.
> Different stream IDs from VPU would be associated to one of these CB.
> The patch ensures to handle CBs which are described as iommu-map in DT.
> Multiple CBs are needed to increase the IOVA for the video usecases like
> higher concurrent sessions.
> 
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>   .../platform/qcom/iris/iris_platform_common.h      | 29 ++++++++++++
>   drivers/media/platform/qcom/iris/iris_probe.c      | 55 ++++++++++++++++++++--
>   drivers/media/platform/qcom/iris/iris_resources.c  | 35 ++++++++++++++
>   drivers/media/platform/qcom/iris/iris_resources.h  |  1 +
>   4 files changed, 116 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
> index 5a489917580eb10022fdcb52f7321a915e8b239d..d2d7c898fc8ef0de1b16aebd72681ea3c5b736ae 100644
> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
> @@ -204,6 +204,33 @@ struct icc_vote_data {
>   	u32 fps;
>   };
>   
> +enum iris_iommu_map_function_id {
> +	IRIS_CB_NON_SECURE_NON_PIXEL	= 0x100,
> +	IRIS_CB_NON_SECURE_PIXEL	= 0x101,
> +	IRIS_CB_NON_SECURE_BITSTREAM	= 0x102,
> +	IRIS_CB_SECURE_NON_PIXEL	= 0x200,
> +	IRIS_CB_SECURE_PIXEL		= 0x201,
> +	IRIS_CB_SECURE_BITSTREAM	= 0x202,
> +	IRIS_CB_FIRMWARE		= 0x300,
> +};
> +
> +enum iris_buffer_region {
> +	IRIS_NON_SECURE_NON_PIXEL	= BIT(0),
> +	IRIS_NON_SECURE_PIXEL		= BIT(1),
> +	IRIS_NON_SECURE_BITSTREAM	= BIT(2),
> +	IRIS_SECURE_NON_PIXEL		= BIT(3),
> +	IRIS_SECURE_PIXEL		= BIT(4),
> +	IRIS_SECURE_BITSTREAM		= BIT(5),
> +};
> +
> +struct iris_context_bank {
> +	struct device *dev;
> +	const char *name;
> +	const enum iris_iommu_map_function_id f_id;
> +	const enum iris_buffer_region region;
> +	const u64 dma_mask;
> +};
> +
>   enum platform_pm_domain_type {
>   	IRIS_CTRL_POWER_DOMAIN,
>   	IRIS_HW_POWER_DOMAIN,
> @@ -246,6 +273,8 @@ struct iris_platform_data {
>   	u32 inst_fw_caps_enc_size;
>   	const struct tz_cp_config *tz_cp_config_data;
>   	u32 tz_cp_config_data_size;
> +	struct iris_context_bank *cb_data;
> +	u32 cb_data_size;
>   	u32 core_arch;
>   	u32 hw_response_timeout;
>   	struct ubwc_config_data *ubwc_config;
> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> index ddaacda523ecb9990af0dd0640196223fbcc2cab..c1a6aac5a3d65d980c5a34ba5fa1c1dbcf790ec5 100644
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> @@ -123,6 +123,37 @@ static int iris_init_resets(struct iris_core *core)
>   				     core->iris_platform_data->controller_rst_tbl_size);
>   }
>   
> +static int iris_init_context_bank_devices(struct iris_core *core)
> +{
> +	struct iris_context_bank *cb;
> +	const __be32 *map_data;
> +	int tupple_size = 5;
> +	int i, j, ret, len;
> +	u32 fid;
> +
> +	map_data = of_get_property(core->dev->of_node, "iommu-map", &len);

If despite proposing all this hackery in the common OF code you're then 
_still_ going to open-code your own parsing of the property, with 
hard-coded assumptions to boot, then clearly this is not the appropriate 
approach at all...

> +	if (!map_data)
> +		return 0;
> +
> +	len /= sizeof(__be32);
> +
> +	for (i = 0; i < len; i += tupple_size) {
> +		fid = be32_to_cpu(map_data[i]);
> +
> +		for (j = 0; j < core->iris_platform_data->cb_data_size; j++) {
> +			cb = &core->iris_platform_data->cb_data[j];
> +
> +			if (fid == cb->f_id && !cb->dev) {
> +				ret = iris_create_child_device_and_map(core, cb);
> +				if (ret)
> +					return ret;
> +			}
> +		}
> +	}
> +
> +	return 0;
> +}
> +
>   static int iris_init_resources(struct iris_core *core)
>   {
>   	int ret;
> @@ -139,7 +170,11 @@ static int iris_init_resources(struct iris_core *core)
>   	if (ret)
>   		return ret;
>   
> -	return iris_init_resets(core);
> +	ret = iris_init_resets(core);
> +	if (ret)
> +		return ret;
> +
> +	return iris_init_context_bank_devices(core);
>   }
>   
>   static int iris_register_video_device(struct iris_core *core, enum domain_type type)
> @@ -187,6 +222,8 @@ static int iris_register_video_device(struct iris_core *core, enum domain_type t
>   static void iris_remove(struct platform_device *pdev)
>   {
>   	struct iris_core *core;
> +	struct device *dev;
> +	int i;
>   
>   	core = platform_get_drvdata(pdev);
>   	if (!core)
> @@ -194,6 +231,14 @@ static void iris_remove(struct platform_device *pdev)
>   
>   	iris_core_deinit(core);
>   
> +	for (i = 0; i < core->iris_platform_data->cb_data_size; i++) {
> +		dev = core->iris_platform_data->cb_data[i].dev;
> +		if (dev) {
> +			platform_device_unregister(to_platform_device(dev));
> +			core->iris_platform_data->cb_data[i].dev = NULL;
> +		}
> +	}
> +
>   	video_unregister_device(core->vdev_dec);
>   	video_unregister_device(core->vdev_enc);
>   
> @@ -277,9 +322,11 @@ static int iris_probe(struct platform_device *pdev)
>   
>   	dma_mask = core->iris_platform_data->dma_mask;
>   
> -	ret = dma_set_mask_and_coherent(dev, dma_mask);
> -	if (ret)
> -		goto err_vdev_unreg_enc;
> +	if (device_iommu_mapped(core->dev)) {
> +		ret = dma_set_mask_and_coherent(core->dev, dma_mask);

Huh? Why would this be conditional? If it's a DMA device then it's a DMA 
device, regardless of whether an IOMMU driver happens to be present or not.

> +		if (ret)
> +			goto err_vdev_unreg_enc;
> +	}
>   
>   	dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
>   	dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
> index 773f6548370a257b8ae7332242544266cbbd61a9..647f6760f2b7a6bab8a585a13eb03cf60a9c047e 100644
> --- a/drivers/media/platform/qcom/iris/iris_resources.c
> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
> @@ -6,6 +6,7 @@
>   #include <linux/clk.h>
>   #include <linux/devfreq.h>
>   #include <linux/interconnect.h>
> +#include <linux/of_device.h>
>   #include <linux/pm_domain.h>
>   #include <linux/pm_opp.h>
>   #include <linux/pm_runtime.h>
> @@ -141,3 +142,37 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
>   
>   	return 0;
>   }
> +
> +int iris_create_child_device_and_map(struct iris_core *core, struct iris_context_bank *cb)
> +{
> +	struct platform_device *pdev;
> +	int ret;
> +
> +	pdev = platform_device_alloc(cb->name, 0);
> +	if (!pdev)
> +		return -ENOMEM;
> +
> +	ret = platform_device_add(pdev);
> +	if (ret) {
> +		platform_device_put(pdev);
> +		return ret;
> +	}
> +
> +	ret = of_dma_configure_id(&pdev->dev, core->dev->of_node, true,
> +				  (const u32 *)&cb->f_id);

No. As I already said before, of_dma_configure() is for bus drivers; if 
you want to act like a bus, implement a proper bus_type with a 
.dma_configure callback. If you don't want to do that then describe the 
individual functional blocks of the codec appropriately as distinct 
devices with distinct hardware properties so the platform bus code can 
handle them correctly. It is not reasonable to advertise physical 
hardware to Linux as a single monolithic device, but then have a driver 
try to pull a "well actually..." by abusing all the internal 
abstractions. The fact that you might happen to avoid the warning from 
iommu_probe_device() because you're not binding drivers to these fake 
platform devices doesn't make this design any less wrong.

Thanks,
Robin.

> +	if (ret)
> +		goto error_unregister;
> +
> +	ret = dma_set_mask_and_coherent(&pdev->dev, cb->dma_mask);
> +	if (ret)
> +		goto error_unregister;
> +
> +	cb->dev = &pdev->dev;
> +
> +	return 0;
> +
> +error_unregister:
> +	platform_device_unregister(to_platform_device(&pdev->dev));
> +
> +	return ret;
> +}
> diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
> index 6bfbd2dc6db095ec05e53c894e048285f82446c6..b7efe15facb203eea9ae13d5f0abdcc2ea718b4d 100644
> --- a/drivers/media/platform/qcom/iris/iris_resources.h
> +++ b/drivers/media/platform/qcom/iris/iris_resources.h
> @@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
>   int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
>   int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
>   int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
> +int iris_create_child_device_and_map(struct iris_core *core, struct iris_context_bank *cb);
>   
>   #endif
> 

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Dmitry Baryshkov]

On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> compared to previous generation, iris3x, it has,
> - separate power domains for stream and pixel processing hardware blocks
>   (bse and vpp).
> - additional power domain for apv codec.
> - power domains for individual pipes (VPPx).
> - different clocks and reset lines.
> 
> iommu-map include all the different stream-ids which can be possibly
> generated by vpu4 hardware.

It's not how it can be defined.

> 
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>  1 file changed, 234 insertions(+)
> 
> +
> +  iommu-map: true

This is totally underspecifified.

> +
> +  memory-region:
> +    maxItems: 1
> +

> +
> +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
> +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
> +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
> +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
> +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
> +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
> +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
> +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
> +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;

#define the functions in the ABI, provide them in the bindings.

> +

-- 
With best wishes
Dmitry

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

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

Hi,

Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> 

[..]

> 
> >  - 4 testcase failed due to unsupported resolution
> 
> Can it be fixed?

Its nicer if you name the failing tests vectors. I can guess this is
PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
level impose a limit on bandwidth, not on resolution. These files are either
very large and small height or the opposite. One of these is just 4K in portrait
mode (that is more concerning). Though, there is a V4L2 limitation for this
aspect, since we advertise the resolutions by range. Most hardware is designed
to support 4096x4096, in that casse that's what you should expose as limits.

Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
this case there is not much you can do, you have to find the right trade of. But
since you expose LEVELs, I think its fine to overshoot a little. Both
constraints should ensure it works with valid streams.

> 
> >  - 2 testcase failed due to CRC mismatch

These are clear example of "no one can guess".

> 
> Which means an error in the testsuite or somewhere on our side?

The testsuite fully pass if you run using Franhofer reference decoder. This is
logical since the MD5 has been generated with it.

> 
> >  - 2 test fails due to session error (under debug)
> >    - PICSIZE_C_Bossen_1

Hmm, see, I have no idea which fourth one could fail due to resolution, and that
forth one is likely a bug on your side.

> >    - WPP_E_ericsson_MAIN_2
> > 
> > VP9:
> > 235/305 testcases passed while testing VP9-TEST-VECTORS with
> >  GStreamer-VP9-V4L2-Gst1.0.
> >  The failing test case:
> >  - 64 testcases failed due to unsupported resolution
> 
> Can it be fixed?

Check if you aren't mixing up constraints between display, coded and allocated
resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
not care at all, or use it to allow optimistic pre-allocation. But check that
the low resolution constraints is not coming from the OUTPUT queue software.

VP9 coded resolution, it always at least 64x64.

> 
> >  - 2 testcases failed due to unsupported format
> 
> Hmm?

Clarify please, I suppose these are YUV444 (aka professional profiles).

> 
> >  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> 
> Could you please raise an issue against fluster?

Check your setup, it fully pass with reference here. The MD5 has been generated
using the reference.

  ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS

It also fully pass with the GStreamer wrapper, though it had been fixed in
recent GStreamer versions (I'm testing with 1.26.10).

> 
> >  - 2 testcase failed due to unsupported resolution after sequence change
> 
> Can it be fixed?

This one can't be fixed without adding an extension to the V4L2 Stateful Decoder
spec, like we did for the stateless decoder spec. In order to handle inter-frame
resolution changes (a resolution change on a non-keyframe), you have to notify
userspace with the new resolution, give it a way to read back this solution,
have CREATE_BUFS() support to allow allocating for that new resolution without
going through streamoff (to avoid looking reference data), and finally, a way to
remove buffers that are now too small (or too big if userspace wants to reduce
the amount of RAM used) through the new DELETE_BUFS ioctl. You also have to
track in your driver the reference buffer resolution/stride.

This is non-trivial with the existing stateful state-machine. You have to make
sure userspace won't be confused between normal DRC and inter-frame DRC (dynamic
resolution changes).


[...]

regards,
Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Vikash Garodia]

On 1/27/2026 8:40 PM, Nicolas Dufresne wrote:
> Hi,
> 
> Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
>> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
>>
> 
> [..]
> 
>>
>>>   - 4 testcase failed due to unsupported resolution
>>
>> Can it be fixed?
> 
> Its nicer if you name the failing tests vectors. I can guess this is
> PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
> level impose a limit on bandwidth, not on resolution. These files are either
> very large and small height or the opposite. One of these is just 4K in portrait
> mode (that is more concerning). Though, there is a V4L2 limitation for this
> aspect, since we advertise the resolutions by range. Most hardware is designed
> to support 4096x4096, in that casse that's what you should expose as limits.
> 
> Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
> this case there is not much you can do, you have to find the right trade of. But
> since you expose LEVELs, I think its fine to overshoot a little. Both
> constraints should ensure it works with valid streams.

I can list the failing test vectors for failing tests. In this case, its
PICSIZE_A_Bossen_1
PICSIZE_B_Bossen_1
WPP_D_ericsson_MAIN10_2
WPP_D_ericsson_MAIN_2

I have not explicitly gone through individual failures this time on 
kaanapali, as last time when these were analyzed for earlier platform 
(SM8550), the failed due to resolution lower than 96x96, which VPU does 
not support for kaanapali as well.

Do you think if fluster can query the supported frame sizes and 
accordingly, mark the ones testing outside that range as pass, if 
graceful error ?

>>
>>>   - 2 testcase failed due to CRC mismatch
> 
> These are clear example of "no one can guess".
> 

RAP_A_docomo_6
VPSSPSPPS_A_MainConcept_1

For "RAP.." test vector, it was discussed earlier [1] and the frames 
marked as VB2_BUF_STATE_ERROR should be dropped. GST is currently 
displaying the NULL content leading to CRC mismatch. Let me know if this 
can be taken up as a GST bug.

[1] 
https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/

>>
>> Which means an error in the testsuite or somewhere on our side?
> 
> The testsuite fully pass if you run using Franhofer reference decoder. This is
> logical since the MD5 has been generated with it.

Since the reference decoder in this is not generating buffers with zero 
filled data, its not complaining. In VPU case, even though buffers are 
of zero filled data, marking them as error, should get dropped, instead 
of considering it as a valid frame.

> 
>>
>>>   - 2 test fails due to session error (under debug)
>>>     - PICSIZE_C_Bossen_1
> 
> Hmm, see, I have no idea which fourth one could fail due to resolution, and that
> forth one is likely a bug on your side.
> 

This could pass on sm8550 and fails on kaanapali. This should be 
debugged from driver side.

>>>     - WPP_E_ericsson_MAIN_2
>>>
>>> VP9:
>>> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>>>   GStreamer-VP9-V4L2-Gst1.0.
>>>   The failing test case:
>>>   - 64 testcases failed due to unsupported resolution
>>
>> Can it be fixed?
> 
> Check if you aren't mixing up constraints between display, coded and allocated
> resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
> not care at all, or use it to allow optimistic pre-allocation. But check that
> the low resolution constraints is not coming from the OUTPUT queue software.
> 
> VP9 coded resolution, it always at least 64x64.
> 
The failed list is same as the one published during sm8550 [1]. I see 
most of the test vectors are <= 64x64 and going as low as 08x08. Here as 
well if we can have a query for supported frame size, it should handle 
these cases.

[1] 
https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
>>
>>>   - 2 testcases failed due to unsupported format
>>
>> Hmm?
> 
> Clarify please, I suppose these are YUV444 (aka professional profiles).

vp91-2-04-yuv422.webm
vp91-2-04-yuv444.webm

> 
>>
>>>   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
>>
>> Could you please raise an issue against fluster?
> 
> Check your setup, it fully pass with reference here. The MD5 has been generated
> using the reference.
> 
>    ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS
> 
> It also fully pass with the GStreamer wrapper, though it had been fixed in
> recent GStreamer versions (I'm testing with 1.26.10).
> 

I would let Dikshita comment on this. I am unable to find that 
discussion where it was failing in her setup with reference decoder as well.

>>
>>>   - 2 testcase failed due to unsupported resolution after sequence change
>>
>> Can it be fixed?
> 
> This one can't be fixed without adding an extension to the V4L2 Stateful Decoder
> spec, like we did for the stateless decoder spec. In order to handle inter-frame
> resolution changes (a resolution change on a non-keyframe), you have to notify
> userspace with the new resolution, give it a way to read back this solution,
> have CREATE_BUFS() support to allow allocating for that new resolution without
> going through streamoff (to avoid looking reference data), and finally, a way to
> remove buffers that are now too small (or too big if userspace wants to reduce
> the amount of RAM used) through the new DELETE_BUFS ioctl. You also have to
> track in your driver the reference buffer resolution/stride.
> 
> This is non-trivial with the existing stateful state-machine. You have to make
> sure userspace won't be confused between normal DRC and inter-frame DRC (dynamic
> resolution changes).
> 
> 
> [...]
> 
> regards,
> Nicolas

Regards,
Vikash

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

[Vikash Garodia]

On 1/27/2026 5:22 PM, Dmitry Baryshkov wrote:
> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
>>
>> On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
>>>> Qualcomm kaanapali platform have a newer generation of video IP iris4.
>>>> The hardware have evolved mostly with respect to higher number of power
>>>> domains as well as multiple clock sources.
>>>>
>>>> The series extends support for multiple iommu-map entries for the same
>>>> input id. Considering iris as a client driver, it adds the handling for
>>>> multiple stream ids from VPU via iommu-map.
>>>>
>>>> This series is depend on the below series:
>>>> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
>>>>
>>>> Following are the compliance and functional validation reports.
>>>
>>> Please validate with fluster too. Having a "knowingly good" command line
>>> is not a validation. It can't be reproduced by anybody else.
>>>
>>
>> Below is the fluster result on kaanapali (will add in cover letter in next
>> revision)
> 
> Nice, thanks!
> 
>>
>> H264:
>> 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
> 
> What about the extension testsuites? Even if they are not supported,
> they should not crash or cause the timeouts.
> 
>> - 52 test vectors failed due to interlaced clips - not supported
> 
> Yet or completely? Does "failed" mean "returned an error" or something
> else?

completely. Driver returns error on firmware detecting the content as 
interlace.

> 
>> - 3 test vectors failed due to unsupported bitstream.
>> - 2 test vectors failed because SP_SLICE type - not supported by the
>>    hardware.
>> - 1 test vector failed due to unsupported profile
>>
>> H265:
>>   129/147 testcases passed while testing JCT-VC-HEVC_V1 with
>>   GStreamer-H.265-V4L2-Gst1.0.
>>   The failing test case:
>>   - 10 testcases failed due to unsupported 10 bit format.
> 
> MAIN10? I was actually surprised, Venus driver supported them for the
> Iris2 hardware. Is it somethething to be fixed in future?

10bit would be added in iris. We are catching up with all the codecs, 
10bit should be next from decoder side.

> 
>>   - 4 testcase failed due to unsupported resolution
> 
> Can it be fixed?
> 
>>   - 2 testcase failed due to CRC mismatch
> 
> Which means an error in the testsuite or somewhere on our side?
> 
>>   - 2 test fails due to session error (under debug)
>>     - PICSIZE_C_Bossen_1
>>     - WPP_E_ericsson_MAIN_2
>>
>> VP9:
>> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>>   GStreamer-VP9-V4L2-Gst1.0.
>>   The failing test case:
>>   - 64 testcases failed due to unsupported resolution
> 
> Can it be fixed?
> 
>>   - 2 testcases failed due to unsupported format
> 
> Hmm?
> 
>>   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> 
> Could you please raise an issue against fluster?
> 
>>   - 2 testcase failed due to unsupported resolution after sequence change
> 
> Can it be fixed?
> 
>>   - 1 testcase failed due to unsupported stream
> 
> ?
> 
>>
>>>> gstreamer test:
>>>> Decoders validated with below commands, codec specific:
>>>> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
>>>> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>
>>> Neither of these commands specify, what exactly was validated. They
>>> specify that you've validated _some_ videos. It's impossible to even
>>> reproduce your results, because you don't specify which files you've
>>> used.
>>>
>>
>> commands are shared indicating the pipeline used for validation for
>> different codec plugins. These are some basic encode and decode commands,
>> and shared for reference for anyone to pick input test files of their own.
> 
> Thanks, but it would also be helpful if you stated, which filesets were
> used for validation. There are enough public filesets for testing video
> decoders.

Ack, will add that info in the cover letter in next revision.

>>
>>>>
>>>> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
>>>> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
>>>> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> Encoders validated with below commands:
>>>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>>>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
>>>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>>>> location=<output_file.h264>
>>>
>>> At least these should use test sinks in order to be reproducible.
>>
>> it is using filesink in the pipeline to generate the encoded bitstream
> 
> I should have been more explicit: test sinks to generate the image.
> 

If you could suggest a gst pipeline for it, i can give it a try.

Regards,
Vikash

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

[Dmitry Baryshkov]

On Tue, Jan 27, 2026 at 09:41:01PM +0530, Vikash Garodia wrote:
> 
> On 1/27/2026 5:22 PM, Dmitry Baryshkov wrote:
> > On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> > > 
> > > On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> > > > > Qualcomm kaanapali platform have a newer generation of video IP iris4.
> > > > > The hardware have evolved mostly with respect to higher number of power
> > > > > domains as well as multiple clock sources.
> > > > > 
> > > > > The series extends support for multiple iommu-map entries for the same
> > > > > input id. Considering iris as a client driver, it adds the handling for
> > > > > multiple stream ids from VPU via iommu-map.
> > > > > 
> > > > > This series is depend on the below series:
> > > > > Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> > > > > 
> > > > > Following are the compliance and functional validation reports.
> > > > 
> > > > Please validate with fluster too. Having a "knowingly good" command line
> > > > is not a validation. It can't be reproduced by anybody else.
> > > > 
> > > 
> > > Below is the fluster result on kaanapali (will add in cover letter in next
> > > revision)
> > 
> > Nice, thanks!
> > 
> > > 
> > > H264:
> > > 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
> > 
> > What about the extension testsuites? Even if they are not supported,
> > they should not crash or cause the timeouts.
> > 
> > > - 52 test vectors failed due to interlaced clips - not supported
> > 
> > Yet or completely? Does "failed" mean "returned an error" or something
> > else?
> 
> completely. Driver returns error on firmware detecting the content as
> interlace.

Ok. I was more worried about timeouts or other kinds of failures.

> 
> > 
> > > - 3 test vectors failed due to unsupported bitstream.
> > > - 2 test vectors failed because SP_SLICE type - not supported by the
> > >    hardware.
> > > - 1 test vector failed due to unsupported profile
> > > 
> > > H265:
> > >   129/147 testcases passed while testing JCT-VC-HEVC_V1 with
> > >   GStreamer-H.265-V4L2-Gst1.0.
> > >   The failing test case:
> > >   - 10 testcases failed due to unsupported 10 bit format.
> > 
> > MAIN10? I was actually surprised, Venus driver supported them for the
> > Iris2 hardware. Is it somethething to be fixed in future?
> 
> 10bit would be added in iris. We are catching up with all the codecs, 10bit
> should be next from decoder side.

Thanks!

> > > > > gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> > > > > parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> > > > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > > > 
> > > > > gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> > > > > parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> > > > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > > > 
> > > > > Encoders validated with below commands:
> > > > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> > > > > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> > > > > capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> > > > > location=<output_file.h264>
> > > > 
> > > > At least these should use test sinks in order to be reproducible.
> > > 
> > > it is using filesink in the pipeline to generate the encoded bitstream
> > 
> > I should have been more explicit: test sinks to generate the image.
> > 
> 
> If you could suggest a gst pipeline for it, i can give it a try.

gst-launch-1.0 -v videotestsrc pattern=smpte '!' video/x-raw,width=1280,height=720 '!' xvimagesink

There are other patterns supported too:
https://gstreamer.freedesktop.org/documentation/videotestsrc/index.html?gi-language=c#GstVideoTestSrcMotionType

-- 
With best wishes
Dmitry

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

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 8941 bytes --]

Hi,

Le mardi 27 janvier 2026 à 21:29 +0530, Vikash Garodia a écrit :
> 
> On 1/27/2026 8:40 PM, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
> > > On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> > > 
> > 
> > [..]
> > 
> > > 
> > > >   - 4 testcase failed due to unsupported resolution
> > > 
> > > Can it be fixed?
> > 
> > Its nicer if you name the failing tests vectors. I can guess this is
> > PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
> > level impose a limit on bandwidth, not on resolution. These files are either
> > very large and small height or the opposite. One of these is just 4K in portrait
> > mode (that is more concerning). Though, there is a V4L2 limitation for this
> > aspect, since we advertise the resolutions by range. Most hardware is designed
> > to support 4096x4096, in that casse that's what you should expose as limits.
> > 
> > Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
> > this case there is not much you can do, you have to find the right trade of. But
> > since you expose LEVELs, I think its fine to overshoot a little. Both
> > constraints should ensure it works with valid streams.
> 
> I can list the failing test vectors for failing tests. In this case, its
> PICSIZE_A_Bossen_1
> PICSIZE_B_Bossen_1
> WPP_D_ericsson_MAIN10_2
> WPP_D_ericsson_MAIN_2
> 
> I have not explicitly gone through individual failures this time on 
> kaanapali, as last time when these were analyzed for earlier platform 
> (SM8550), the failed due to resolution lower than 96x96, which VPU does 
> not support for kaanapali as well.
> 
> Do you think if fluster can query the supported frame sizes and 
> accordingly, mark the ones testing outside that range as pass, if 
> graceful error ?

No, the conformance streams are the same for all decoder regardless of the
subset of the spec the hardware designers decided have implemented. The error
type could possibly be enhanced, but at the moment we have:

- Success: MD5 matches
- Fail: MD5 does not match (corrupted/truncated outcome)
- Error: When the operation did not complete.

Once you have manually investigated all the case, and you want to setup your CI
(which I strongly recommend you to do). You can pass -sv / --skipvectors
parameter to `run` command to remove the expected fail from your run.

Another thing we get to notice, is that integrator very commonly assume that a
96x96 limits imply that all the resolution, display, coded and allocated must be
at least that big. Which most of the time is not what the HW designers intended.

> 
> > > 
> > > >   - 2 testcase failed due to CRC mismatch
> > 
> > These are clear example of "no one can guess".
> > 
> 
> RAP_A_docomo_6

When I read the description for this one it looks like something normally handle
in the control software (which is in your firmware for this type of hardware).
You should report to your firmware team. When a GOP starts on a CRA followed by
RASL, the control software need to skip over the RASL. This can either be done
by skipping over the decoding, or letting the decoder run but marking as non-
output. The second is what the GStreamer stateless decoders implementation do,
but we notice that on older driver, it may cause errors or hangs, so we will
stop doing that in the future. For reference, you can download the zip (link in
fluster/test_suites/h.265/JCT-VC-HEVC_V1.json), ITU conformances usually come
with a description.

https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/HEVC_v1/RAP_A_docomo_6.zip
RAP_A_docomo_6: (RAP_A_docomo_6.bit)
Frame rate: 30 fps
Picture size: 832x480 
Spec version: HM10.1

(Category: RAP; Sub-category: Bitstream starting with a CRA picture followed by
RASL pictures that cannot be decoded)

The purpose of the stream is to exercise the decoding of a conforming bitstream
where the CRA is the first picture in the bitstream and is followed by 7 RASL
pictures that are not decodable. There are two subsequent CRA pictures with RASL
pictures, following the first CRA picture in this bitstream. These subsequent
RASL pictures should be decodable since the associated CRA is not the first CRA
picture in the bitstream.

Note: In actual decoders, any RASL pictures associated with a CRA picture at the
beginning of the bitstream or any RASL pictures associated with a BLA picture
may be ignored (removed from the bitstream and discarded), as they are not
specified for output and have no effect on the decoding process of any other
pictures that are specified for output.

The MD5 of the yuv file in output order decoded using the HM10.1-dev-3420 is
included in RAP_A_docomo_6.md5.


> VPSSPSPPS_A_MainConcept_1

This one depends on software cropping happening after the decoder. This is not
implemented in v4l2 stateful decoder, so a GStreamer bug. Unaligned crop regions
that cannot be cropped by offset and stride stricks are generally not supported,
but we opted for a proper cropper in the stateless plugin in order to support
conformance testing. Patched welcome, but not an issue with this driver.

> 
> For "RAP.." test vector, it was discussed earlier [1] and the frames 
> marked as VB2_BUF_STATE_ERROR should be dropped. GST is currently 
> displaying the NULL content leading to CRC mismatch. Let me know if this 
> can be taken up as a GST bug.

Well, as discussed earlier, GStreamer drops the ERROR frame if their payload
size it reset to 0. Otherwise its treated as partially corrupted frame, and
pushed. This aligns with how the v4l2 buffer error state is documented.

> 
> [1] 
> https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
> 
> > > 
> > > Which means an error in the testsuite or somewhere on our side?
> > 
> > The testsuite fully pass if you run using Franhofer reference decoder. This is
> > logical since the MD5 has been generated with it.
> 
> Since the reference decoder in this is not generating buffers with zero 
> filled data, its not complaining. In VPU case, even though buffers are 
> of zero filled data, marking them as error, should get dropped, instead 
> of considering it as a valid frame.

See comment below, you have some debugging to do here. I think other dev in your
group have kept ignoring the problem.

> 
> > 
> > > 
> > > >   - 2 test fails due to session error (under debug)
> > > >     - PICSIZE_C_Bossen_1
> > 
> > Hmm, see, I have no idea which fourth one could fail due to resolution, and that
> > forth one is likely a bug on your side.
> > 
> 
> This could pass on sm8550 and fails on kaanapali. This should be 
> debugged from driver side.
> 
> > > >     - WPP_E_ericsson_MAIN_2
> > > > 
> > > > VP9:
> > > > 235/305 testcases passed while testing VP9-TEST-VECTORS with
> > > >   GStreamer-VP9-V4L2-Gst1.0.
> > > >   The failing test case:
> > > >   - 64 testcases failed due to unsupported resolution
> > > 
> > > Can it be fixed?
> > 
> > Check if you aren't mixing up constraints between display, coded and allocated
> > resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
> > not care at all, or use it to allow optimistic pre-allocation. But check that
> > the low resolution constraints is not coming from the OUTPUT queue software.
> > 
> > VP9 coded resolution, it always at least 64x64.
> > 
> The failed list is same as the one published during sm8550 [1]. I see 
> most of the test vectors are <= 64x64 and going as low as 08x08. Here as 
> well if we can have a query for supported frame size, it should handle 
> these cases.
> 
> [1] 
> https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
> > > 
> > > >   - 2 testcases failed due to unsupported format
> > > 
> > > Hmm?
> > 
> > Clarify please, I suppose these are YUV444 (aka professional profiles).
> 
> vp91-2-04-yuv422.webm
> vp91-2-04-yuv444.webm
> 
> > 
> > > 
> > > >   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> > > 
> > > Could you please raise an issue against fluster?
> > 
> > Check your setup, it fully pass with reference here. The MD5 has been generated
> > using the reference.
> > 
> >    ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS
> > 
> > It also fully pass with the GStreamer wrapper, though it had been fixed in
> > recent GStreamer versions (I'm testing with 1.26.10).
> > 
> 
> I would let Dikshita comment on this. I am unable to find that 
> discussion where it was failing in her setup with reference decoder as well.

Looking forward some improvement over generation of hardware, not regression.

regards,
Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 3/7] of/iommu: add multi-map support

[Vijayanand Jitta]

On 1/27/2026 7:50 PM, Robin Murphy wrote:
> On 2026-01-27 11:45 am, Dmitry Baryshkov wrote:
>> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>>
>>> When multiple mappings are present for an input id, linux matches just
>>> the first one. There is a usecase[1] where all the mappings are to be
>>> maintained in parallel for an iommu-map entry of a same input id.
>>
>> This contradicts the IOMMU idealogy (at least as far as I understood it
>> fom the maintainers): the device (driver) doesn't control which IOMMUs
>> are getting used. Instead _all_ defined entries should get used. For
>> iommu-map it means that if the map defines several entries for a single
>> function, then all entries should always get mapped.
> 
> Indeed there is no concept of "multi-map" - if a single input ID represents more than one thing then that notion of "input ID" is fundamentally wrong. A single *device* may have multiple IDs, as in the case of PCI bridge aliasing, but in that case there are multiple things to map.
> 

vpu hardware do have video decode and encode usecases that would generate multiple Stream ID's.
So, all these Stream ID's would need to be represented using single input id as mentioned
in dt binding.

Referring patch [1/7] in this series

iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
            <0x100 &apps_smmu 0x1a20 0x0 0x1>,
	    <0x100 &apps_smmu 0x1944 0x0 0x1>;
		
Here, IRIS_CB_NON_SECURE_NON_PIXEL [1] is the input id.

enum iris_iommu_map_function_id {
  IRIS_CB_NON_SECURE_NON_PIXEL  = 0x100,

[1] https://lore.kernel.org/all/20260126-kaanapali-iris-v1-5-e2646246bfc1@oss.qualcomm.com/ 

Thanks,
Vijay

> Thanks,
> Robin.

Re: [PATCH 5/7] media: iris: add context bank devices using iommu-map

[Vikash Garodia]

On 1/27/2026 8:19 PM, Robin Murphy wrote:
> On 2026-01-26 12:25 pm, Vikash Garodia wrote:
>> Introduce different context banks(CB) and the associated buffer region.
>> Different stream IDs from VPU would be associated to one of these CB.
>> The patch ensures to handle CBs which are described as iommu-map in DT.
>> Multiple CBs are needed to increase the IOVA for the video usecases like
>> higher concurrent sessions.
>>
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   .../platform/qcom/iris/iris_platform_common.h      | 29 ++++++++++++
>>   drivers/media/platform/qcom/iris/iris_probe.c      | 55 ++++++++++++ 
>> ++++++++--
>>   drivers/media/platform/qcom/iris/iris_resources.c  | 35 ++++++++++++++
>>   drivers/media/platform/qcom/iris/iris_resources.h  |  1 +
>>   4 files changed, 116 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h 
>> b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 
>> 5a489917580eb10022fdcb52f7321a915e8b239d..d2d7c898fc8ef0de1b16aebd72681ea3c5b736ae 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -204,6 +204,33 @@ struct icc_vote_data {
>>       u32 fps;
>>   };
>> +enum iris_iommu_map_function_id {
>> +    IRIS_CB_NON_SECURE_NON_PIXEL    = 0x100,
>> +    IRIS_CB_NON_SECURE_PIXEL    = 0x101,
>> +    IRIS_CB_NON_SECURE_BITSTREAM    = 0x102,
>> +    IRIS_CB_SECURE_NON_PIXEL    = 0x200,
>> +    IRIS_CB_SECURE_PIXEL        = 0x201,
>> +    IRIS_CB_SECURE_BITSTREAM    = 0x202,
>> +    IRIS_CB_FIRMWARE        = 0x300,
>> +};
>> +
>> +enum iris_buffer_region {
>> +    IRIS_NON_SECURE_NON_PIXEL    = BIT(0),
>> +    IRIS_NON_SECURE_PIXEL        = BIT(1),
>> +    IRIS_NON_SECURE_BITSTREAM    = BIT(2),
>> +    IRIS_SECURE_NON_PIXEL        = BIT(3),
>> +    IRIS_SECURE_PIXEL        = BIT(4),
>> +    IRIS_SECURE_BITSTREAM        = BIT(5),
>> +};
>> +
>> +struct iris_context_bank {
>> +    struct device *dev;
>> +    const char *name;
>> +    const enum iris_iommu_map_function_id f_id;
>> +    const enum iris_buffer_region region;
>> +    const u64 dma_mask;
>> +};
>> +
>>   enum platform_pm_domain_type {
>>       IRIS_CTRL_POWER_DOMAIN,
>>       IRIS_HW_POWER_DOMAIN,
>> @@ -246,6 +273,8 @@ struct iris_platform_data {
>>       u32 inst_fw_caps_enc_size;
>>       const struct tz_cp_config *tz_cp_config_data;
>>       u32 tz_cp_config_data_size;
>> +    struct iris_context_bank *cb_data;
>> +    u32 cb_data_size;
>>       u32 core_arch;
>>       u32 hw_response_timeout;
>>       struct ubwc_config_data *ubwc_config;
>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/ 
>> media/platform/qcom/iris/iris_probe.c
>> index 
>> ddaacda523ecb9990af0dd0640196223fbcc2cab..c1a6aac5a3d65d980c5a34ba5fa1c1dbcf790ec5 100644
>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>> @@ -123,6 +123,37 @@ static int iris_init_resets(struct iris_core *core)
>>                        core->iris_platform_data- 
>> >controller_rst_tbl_size);
>>   }
>> +static int iris_init_context_bank_devices(struct iris_core *core)
>> +{
>> +    struct iris_context_bank *cb;
>> +    const __be32 *map_data;
>> +    int tupple_size = 5;
>> +    int i, j, ret, len;
>> +    u32 fid;
>> +
>> +    map_data = of_get_property(core->dev->of_node, "iommu-map", &len);
> 
> If despite proposing all this hackery in the common OF code you're then 
> _still_ going to open-code your own parsing of the property, with hard- 
> coded assumptions to boot, then clearly this is not the appropriate 
> approach at all...
> 

Ack, we should avoid parsing this in video driver.


>> +    if (!map_data)
>> +        return 0;
>> +
>> +    len /= sizeof(__be32);
>> +
>> +    for (i = 0; i < len; i += tupple_size) {
>> +        fid = be32_to_cpu(map_data[i]);
>> +
>> +        for (j = 0; j < core->iris_platform_data->cb_data_size; j++) {
>> +            cb = &core->iris_platform_data->cb_data[j];
>> +
>> +            if (fid == cb->f_id && !cb->dev) {
>> +                ret = iris_create_child_device_and_map(core, cb);
>> +                if (ret)
>> +                    return ret;
>> +            }
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>   static int iris_init_resources(struct iris_core *core)
>>   {
>>       int ret;
>> @@ -139,7 +170,11 @@ static int iris_init_resources(struct iris_core 
>> *core)
>>       if (ret)
>>           return ret;
>> -    return iris_init_resets(core);
>> +    ret = iris_init_resets(core);
>> +    if (ret)
>> +        return ret;
>> +
>> +    return iris_init_context_bank_devices(core);
>>   }
>>   static int iris_register_video_device(struct iris_core *core, enum 
>> domain_type type)
>> @@ -187,6 +222,8 @@ static int iris_register_video_device(struct 
>> iris_core *core, enum domain_type t
>>   static void iris_remove(struct platform_device *pdev)
>>   {
>>       struct iris_core *core;
>> +    struct device *dev;
>> +    int i;
>>       core = platform_get_drvdata(pdev);
>>       if (!core)
>> @@ -194,6 +231,14 @@ static void iris_remove(struct platform_device 
>> *pdev)
>>       iris_core_deinit(core);
>> +    for (i = 0; i < core->iris_platform_data->cb_data_size; i++) {
>> +        dev = core->iris_platform_data->cb_data[i].dev;
>> +        if (dev) {
>> +            platform_device_unregister(to_platform_device(dev));
>> +            core->iris_platform_data->cb_data[i].dev = NULL;
>> +        }
>> +    }
>> +
>>       video_unregister_device(core->vdev_dec);
>>       video_unregister_device(core->vdev_enc);
>> @@ -277,9 +322,11 @@ static int iris_probe(struct platform_device *pdev)
>>       dma_mask = core->iris_platform_data->dma_mask;
>> -    ret = dma_set_mask_and_coherent(dev, dma_mask);
>> -    if (ret)
>> -        goto err_vdev_unreg_enc;
>> +    if (device_iommu_mapped(core->dev)) {
>> +        ret = dma_set_mask_and_coherent(core->dev, dma_mask);
> 
> Huh? Why would this be conditional? If it's a DMA device then it's a DMA 
> device, regardless of whether an IOMMU driver happens to be present or not.

added to support existing DTS which have iommus property. For parent 
node, not having the iommus property and dma_set_mask_and_coherent is 
called for parent device, it errors.

> 
>> +        if (ret)
>> +            goto err_vdev_unreg_enc;
>> +    }
>>       dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
>>       dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/ 
>> drivers/media/platform/qcom/iris/iris_resources.c
>> index 
>> 773f6548370a257b8ae7332242544266cbbd61a9..647f6760f2b7a6bab8a585a13eb03cf60a9c047e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.c
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
>> @@ -6,6 +6,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/devfreq.h>
>>   #include <linux/interconnect.h>
>> +#include <linux/of_device.h>
>>   #include <linux/pm_domain.h>
>>   #include <linux/pm_opp.h>
>>   #include <linux/pm_runtime.h>
>> @@ -141,3 +142,37 @@ int iris_disable_unprepare_clock(struct iris_core 
>> *core, enum platform_clk_type
>>       return 0;
>>   }
>> +
>> +int iris_create_child_device_and_map(struct iris_core *core, struct 
>> iris_context_bank *cb)
>> +{
>> +    struct platform_device *pdev;
>> +    int ret;
>> +
>> +    pdev = platform_device_alloc(cb->name, 0);
>> +    if (!pdev)
>> +        return -ENOMEM;
>> +
>> +    ret = platform_device_add(pdev);
>> +    if (ret) {
>> +        platform_device_put(pdev);
>> +        return ret;
>> +    }
>> +
>> +    ret = of_dma_configure_id(&pdev->dev, core->dev->of_node, true,
>> +                  (const u32 *)&cb->f_id);
> 
> No. As I already said before, of_dma_configure() is for bus drivers; if 
> you want to act like a bus, implement a proper bus_type with 
> a .dma_configure callback. If you don't want to do that then describe 
> the individual functional blocks of the codec appropriately as distinct 
> devices with distinct hardware properties so the platform bus code can 
> handle them correctly. It is not reasonable to advertise physical 
> hardware to Linux as a single monolithic device, but then have a driver 
> try to pull a "well actually..." by abusing all the internal 
> abstractions. The fact that you might happen to avoid the warning from 
> iommu_probe_device() because you're not binding drivers to these fake 
> platform devices doesn't make this design any less wrong.
>

VPU would have _only_ distinct stream-ids for distinct hardware sub 
blocks, would that classify them as distinct devices with distinct 
hardware properties so as to use platform bus ?

Here is what i posted earlier with "iris_non_pixel" as one of sub-block,

https://lore.kernel.org/linux-media/20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com/

Regards,
Vikash

> Thanks,
> Robin.
> 
>> +    if (ret)
>> +        goto error_unregister;
>> +
>> +    ret = dma_set_mask_and_coherent(&pdev->dev, cb->dma_mask);
>> +    if (ret)
>> +        goto error_unregister;
>> +
>> +    cb->dev = &pdev->dev;
>> +
>> +    return 0;
>> +
>> +error_unregister:
>> +    platform_device_unregister(to_platform_device(&pdev->dev));
>> +
>> +    return ret;
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/ 
>> drivers/media/platform/qcom/iris/iris_resources.h
>> index 
>> 6bfbd2dc6db095ec05e53c894e048285f82446c6..b7efe15facb203eea9ae13d5f0abdcc2ea718b4d 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.h
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.h
>> @@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
>>   int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
>>   int iris_disable_unprepare_clock(struct iris_core *core, enum 
>> platform_clk_type clk_type);
>>   int iris_prepare_enable_clock(struct iris_core *core, enum 
>> platform_clk_type clk_type);
>> +int iris_create_child_device_and_map(struct iris_core *core, struct 
>> iris_context_bank *cb);
>>   #endif
>>
> 

Re: [PATCH 2/7] of: factor out of_map_id() code

[Bryan O'Donoghue]

On 26/01/2026 12:25, Vikash Garodia wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>

This commit message is confusing and inaccurate.

First up, you're not factoring _out_ of_map_id() - factor out 
of_map_id() means to remove of_map_id() - you are refactoring of_map_id().

Your patch title should be something like "refactor of_map_id() to 
prepare for mapping of multiple IDs to a single device"

> Linux interprets multiple mappings for the same input ID as a set of
> equivalent choices to pick one. There exists usecases where these set
> must be maintained in parallel, ex: on ARM, a dynamically created child
> device(s) is referencing multiple input id's in parent iommu-map.
> 
> Factor out the code where multiple mappings needs to be maintained in
> parallel can be achieved through callback from this factored out code.

Which callback ? There is no ->function(pointer, here...); ?!

Just make some plain and straightforward statements about what you are 
doing and why. There's no need to resort to dissertation-speak.

> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>   drivers/of/base.c | 47 ++++++++++++++++++++++++++++++++---------------
>   1 file changed, 32 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 0825f3dc93f2472e9947af09acdde72031ab85bc..606bef4f90e7d13bae4f7b0c45acd1755ad89826 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2122,6 +2122,32 @@ static bool of_check_bad_map(const __be32 *map, int len)
>   	return true;
>   }
>   
> +static int of_map_id_fill_output(struct of_map_id_arg *arg,
> +				 struct device_node *phandle_node, u32 id_or_offset,
> +				 const __be32 *out_base, u32 cells,
> +				 bool bypass)
> +{
> +	if (bypass) {
> +		arg->map_args.args[0] = id_or_offset;
> +		return 0;
> +	}
> +
> +	if (arg->map_args.np)
> +		of_node_put(phandle_node);
> +	else
> +		arg->map_args.np = phandle_node;
> +
> +	if (arg->map_args.np != phandle_node)
> +		return -EAGAIN;
> +
> +	for (int i = 0; i < cells; i++)
> +		arg->map_args.args[i] = (id_or_offset + be32_to_cpu(out_base[i]));
> +
> +	arg->map_args.args_count = cells;
> +
> +	return 0;
> +}
> +
>   /**
>    * of_map_id - Translate an ID through a downstream mapping.
>    * @np: root complex device node.
> @@ -2162,8 +2188,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   		if (arg->map_args.np)
>   			return -ENODEV;
>   		/* Otherwise, no map implies no translation */
> -		arg->map_args.args[0] = id;
> -		return 0;
> +		goto bypass_translation;
>   	}
>   
>   	if (map_bytes % sizeof(*map))
> @@ -2185,6 +2210,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   		struct device_node *phandle_node;
>   		u32 id_base, phandle, id_len, id_off, cells = 0;
>   		const __be32 *out_base;
> +		int ret;
>   
>   		if (map_len - offset < 2)
>   			goto err_map_len;
> @@ -2238,19 +2264,10 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   		if (masked_id < id_base || id_off >= id_len)
>   			continue;
>   
> -		if (arg->map_args.np)
> -			of_node_put(phandle_node);
> -		else
> -			arg->map_args.np = phandle_node;
> -
> -		if (arg->map_args.np != phandle_node)
> +		ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
> +		if (ret == -EAGAIN)
>   			continue;
>   
> -		for (int i = 0; i < cells; i++)
> -			arg->map_args.args[i] = (id_off + be32_to_cpu(out_base[i]));
> -
> -		arg->map_args.args_count = cells;
> -
>   		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
>   			np, map_name, map_mask, id_base, be32_to_cpup(out_base),
>   			id_len, id, id_off + be32_to_cpup(out_base));
> @@ -2260,9 +2277,9 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
>   		id, arg->map_args.np  ? arg->map_args.np : NULL);
>   
> +bypass_translation:
>   	/* Bypasses translation */
> -	arg->map_args.args[0] = id;
> -	return 0;
> +	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
>   
>   err_map_len:
>   	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
> 

Re: [PATCH 3/7] of/iommu: add multi-map support

[Bryan O'Donoghue]

On 26/01/2026 12:25, Vikash Garodia wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> 
> When multiple mappings are present for an input id, linux matches just
> the first one. There is a usecase[1] where all the mappings are to be
> maintained in parallel for an iommu-map entry of a same input id.
> 
> Whether multi-map is needed is reported by the callers through the
> callback function passed, which is called for every input id match.
> 
> Since the requirement in the usecase[1] is for platform devices, not
> sure if it is really clean to maintain this decision on the bus type at
> the of_iommu layer or further to be from the respective
> iommu_driver->impl_ops().
> 
> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
> 
> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>   drivers/iommu/of_iommu.c | 36 ++++++++++++++++++++++++++++--------
>   drivers/of/base.c        | 38 ++++++++++++++++++++++++++++----------
>   include/linux/of.h       |  6 ++++++
>   3 files changed, 62 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 768eaddf927b0700b2497b08ea21611b1a1b5688..067bb2298973671e1eaf01bb2ea52df3d2a52a44 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -16,6 +16,7 @@
>   #include <linux/pci.h>
>   #include <linux/slab.h>
>   #include <linux/fsl/mc.h>
> +#include <linux/platform_device.h>
>   
>   #include "iommu-priv.h"
>   
> @@ -41,22 +42,41 @@ static int of_iommu_xlate(struct device *dev,
>   	return ret;
>   }
>   
> +/*
> + * Callback to be called from of_map_id(), that tells if
> + * all the mappings for an input id to be maintained in
> + * parallel. Should this decission be from further layers,
> + * iommu_driver->impl_ops?
> + */
> +static int of_iommu_configure_cb(struct of_map_id_arg *arg)
> +{
> +	struct of_phandle_args *iommu_spec = &arg->map_args;
> +	struct device *dev = arg->dev;
> +	int err;
> +
> +	err = of_iommu_xlate(dev, iommu_spec);
> +	of_node_put(iommu_spec->np);
> +
> +	/* !iommu_spec->np may be from the bypassed translations */
> +	if (!err)
> +		err = (!arg->multi_map || !iommu_spec->np) ? 0 : -EAGAIN;
> +
> +	return err;
> +}
> +
>   static int of_iommu_configure_dev_id(struct device_node *master_np,
>   				     struct device *dev,
>   				     const u32 *id)
>   {
>   	struct of_map_id_arg arg = {
>   		.map_args = {},
> +		.cb = of_iommu_configure_cb,
> +		.dev = dev,
> +		/* Should this be pushed to iommu_driver->impl_ops? */
> +		.multi_map = dev_is_platform(dev),
>   	};
> -	int err;
> -
> -	err = of_map_iommu_id(master_np, *id, &arg);
> -	if (err)
> -		return err;
>   
> -	err = of_iommu_xlate(dev, &arg.map_args);
> -	of_node_put(arg.map_args.np);
> -	return err;
> +	return of_map_iommu_id(master_np, *id, &arg);
>   }
>   
>   static int of_iommu_configure_dev(struct device_node *master_np,
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 606bef4f90e7d13bae4f7b0c45acd1755ad89826..a1c3c5954ec7e8eb3753c8fd782a1570f9eb9c17 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2122,14 +2122,21 @@ static bool of_check_bad_map(const __be32 *map, int len)
>   	return true;
>   }
>   
> -static int of_map_id_fill_output(struct of_map_id_arg *arg,
> -				 struct device_node *phandle_node, u32 id_or_offset,
> -				 const __be32 *out_base, u32 cells,
> -				 bool bypass)
> +/*
> + * Fill the id_out and target for the of_map_id() caller. Also
> + * call the callback passed to the of_map_id() as part of the arg
> + * that decides if to continue further search.
> + */
> +static int of_map_id_fill_arg(struct of_map_id_arg *arg,
> +			      struct device_node *phandle_node, u32 id_or_offset,
> +			      const __be32 *out_base, u32 cells,
> +			      bool bypass, bool *multi_id_map)
>   {
> +	int ret;
> +
>   	if (bypass) {
>   		arg->map_args.args[0] = id_or_offset;
> -		return 0;
> +		goto output;
>   	}
>   
>   	if (arg->map_args.np)
> @@ -2145,7 +2152,14 @@ static int of_map_id_fill_output(struct of_map_id_arg *arg,
>   
>   	arg->map_args.args_count = cells;
>   
> -	return 0;
> +output:
> +	/* pass the output for the callback, callers may further decide */
> +	ret =  arg->cb ? arg->cb(arg) : 0;
> +
> +	if (multi_id_map && ret == -EAGAIN)
> +		*multi_id_map = true;
> +
> +	return ret;
>   }
>   
>   /**
> @@ -2179,6 +2193,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   	int map_bytes, map_len, offset = 0;
>   	bool bad_map = false;
>   	const __be32 *map = NULL;
> +	bool multi_id_map = false;
>   
>   	if (!np || !map_name || !arg)
>   		return -EINVAL;
> @@ -2264,23 +2279,26 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>   		if (masked_id < id_base || id_off >= id_len)
>   			continue;
>   
> -		ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
> +		ret = of_map_id_fill_arg(arg, phandle_node, id_off, out_base,
> +					 cells, false, &multi_id_map);
>   		if (ret == -EAGAIN)
>   			continue;
>   
>   		pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
>   			np, map_name, map_mask, id_base, be32_to_cpup(out_base),
>   			id_len, id, id_off + be32_to_cpup(out_base));
> -		return 0;
> +		return ret;
>   	}
>   
> +	if (multi_id_map)
> +		return 0;
> +
>   	pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
>   		id, arg->map_args.np  ? arg->map_args.np : NULL);
>   
>   bypass_translation:
>   	/* Bypasses translation */
> -	return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
> -
> +	return of_map_id_fill_arg(arg, NULL, id, 0, 0, true, NULL);
>   err_map_len:
>   	pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
>   	return -EINVAL;
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 9efa6f93712c6024f05476f9fd39f3294f942ec1..abab73a76682351f5635c1127a6c899917525050 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -25,6 +25,9 @@
>   typedef u32 phandle;
>   typedef u32 ihandle;
>   
> +struct of_map_id_arg;
> +typedef int (*of_map_id_cb)(struct of_map_id_arg *arg);
> +
>   struct property {
>   	char	*name;
>   	int	length;
> @@ -76,6 +79,9 @@ struct of_phandle_args {
>   
>   struct of_map_id_arg {
>   	struct of_phandle_args map_args;
> +	of_map_id_cb cb;
> +	struct device *dev;
> +	bool multi_map;
>   };
>   
>   struct of_phandle_iterator {
> 

I think at a minimum this and the previous patch should be separated 
into its/their own series ∵ you really require this to be applied before 
proceeding on with the rest of the submission.

Get these two patches through iommu@lists.linux.dev in isolation and 
then submit the driver changes to consume.

---
bod

Re: [PATCH 4/7] media: iris: Switch to hardware mode after firmware boot

[Bryan O'Donoghue]

On 26/01/2026 12:25, Vikash Garodia wrote:
> Currently the driver switches the vcodec GDSC to hardware (HW) mode
> before firmware load and boot sequence. GDSC can be powered off,
> keeping in hw mode, thereby the vcodec registers programmed in TrustZone
> (TZ) carry default (reset) values.
> Move the transition to HW mode after firmware load and boot sequence.
> 
> The bug was exposed with driver configuring different stream ids to
> different devices via iommu-map. With registers carrying reset values,
> VPU would not generate desired stream-id, thereby leading to SMMU fault.
> 
> Fixes: dde659d37036 ("media: iris: Introduce vpu ops for vpu4 with necessary hooks")
> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>   drivers/media/platform/qcom/iris/iris_core.c       |  4 ++++
>   drivers/media/platform/qcom/iris/iris_hfi_common.c |  4 ++++
>   drivers/media/platform/qcom/iris/iris_vpu2.c       |  1 +
>   drivers/media/platform/qcom/iris/iris_vpu3x.c      |  9 +++-----
>   drivers/media/platform/qcom/iris/iris_vpu4x.c      | 24 ++++++++++++----------
>   drivers/media/platform/qcom/iris/iris_vpu_common.c | 16 +++++++++------
>   drivers/media/platform/qcom/iris/iris_vpu_common.h |  3 +++
>   7 files changed, 38 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/media/platform/qcom/iris/iris_core.c
> index 8406c48d635b6eba0879396ce9f9ae2292743f09..dbaac01eb15a0e622e85635fddd29c1f7fc18662 100644
> --- a/drivers/media/platform/qcom/iris/iris_core.c
> +++ b/drivers/media/platform/qcom/iris/iris_core.c
> @@ -75,6 +75,10 @@ int iris_core_init(struct iris_core *core)
>   	if (ret)
>   		goto error_unload_fw;
> 
> +	ret = iris_vpu_switch_to_hwmode(core);
> +	if (ret)
> +		goto error_unload_fw;
> +
>   	ret = iris_hfi_core_init(core);
>   	if (ret)
>   		goto error_unload_fw;
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.c b/drivers/media/platform/qcom/iris/iris_hfi_common.c
> index 92112eb16c11048e28230a2926dfb46e3163aada..621c66593d88d47ef3438c98a07cb29421c4e375 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_common.c
> @@ -159,6 +159,10 @@ int iris_hfi_pm_resume(struct iris_core *core)
>   	if (ret)
>   		goto err_suspend_hw;
> 
> +	ret = iris_vpu_switch_to_hwmode(core);
> +	if (ret)
> +		goto err_suspend_hw;
> +
>   	ret = ops->sys_interframe_powercollapse(core);
>   	if (ret)
>   		goto err_suspend_hw;
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu2.c b/drivers/media/platform/qcom/iris/iris_vpu2.c
> index 9c103a2e4e4eafee101a8a9b168fdc8ca76e277d..01ef40f3895743b3784464e2d5ba2de1aeca5a4a 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu2.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu2.c
> @@ -44,4 +44,5 @@ const struct vpu_ops iris_vpu2_ops = {
>   	.power_off_controller = iris_vpu_power_off_controller,
>   	.power_on_controller = iris_vpu_power_on_controller,
>   	.calc_freq = iris_vpu2_calc_freq,
> +	.set_hwmode = iris_vpu_set_hwmode,
>   };
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index fe4423b951b1e9e31d06dffc69d18071cc985731..3dad47be78b58f6cd5ed6f333b3376571a04dbf0 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -234,14 +234,8 @@ static int iris_vpu35_power_on_hw(struct iris_core *core)
>   	if (ret)
>   		goto err_disable_hw_free_clk;
> 
> -	ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
> -	if (ret)
> -		goto err_disable_hw_clk;
> -
>   	return 0;
> 
> -err_disable_hw_clk:
> -	iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>   err_disable_hw_free_clk:
>   	iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>   err_disable_axi_clk:
> @@ -266,6 +260,7 @@ const struct vpu_ops iris_vpu3_ops = {
>   	.power_off_controller = iris_vpu_power_off_controller,
>   	.power_on_controller = iris_vpu_power_on_controller,
>   	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> +	.set_hwmode = iris_vpu_set_hwmode,
>   };
> 
>   const struct vpu_ops iris_vpu33_ops = {
> @@ -274,6 +269,7 @@ const struct vpu_ops iris_vpu33_ops = {
>   	.power_off_controller = iris_vpu33_power_off_controller,
>   	.power_on_controller = iris_vpu_power_on_controller,
>   	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> +	.set_hwmode = iris_vpu_set_hwmode,
>   };
> 
>   const struct vpu_ops iris_vpu35_ops = {
> @@ -283,4 +279,5 @@ const struct vpu_ops iris_vpu35_ops = {
>   	.power_on_controller = iris_vpu35_vpu4x_power_on_controller,
>   	.program_bootup_registers = iris_vpu35_vpu4x_program_bootup_registers,
>   	.calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
> +	.set_hwmode = iris_vpu_set_hwmode,
>   };
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/media/platform/qcom/iris/iris_vpu4x.c
> index a8db02ce5c5ec583c4027166b34ce51d3d683b4e..02e100a4045fced33d7a3545b632cc5f0955233f 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu4x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
> @@ -252,21 +252,10 @@ static int iris_vpu4x_power_on_hardware(struct iris_core *core)
>   		ret = iris_vpu4x_power_on_apv(core);
>   		if (ret)
>   			goto disable_hw_clocks;
> -
> -		iris_vpu4x_ahb_sync_reset_apv(core);
>   	}
> 
> -	iris_vpu4x_ahb_sync_reset_hardware(core);
> -
> -	ret = iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
> -	if (ret)
> -		goto disable_apv_power_domain;
> -
>   	return 0;
> 
> -disable_apv_power_domain:
> -	if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
> -		iris_vpu4x_power_off_apv(core);
>   disable_hw_clocks:
>   	iris_vpu4x_disable_hardware_clocks(core, efuse_value);
>   disable_vpp1_power_domain:
> @@ -359,6 +348,18 @@ static void iris_vpu4x_power_off_hardware(struct iris_core *core)
>   	iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
>   }
> 
> +static int iris_vpu4x_set_hwmode(struct iris_core *core)
> +{
> +	u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
> +
> +	if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
> +		iris_vpu4x_ahb_sync_reset_apv(core);
> +
> +	iris_vpu4x_ahb_sync_reset_hardware(core);
> +
> +	return iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
I'd like to see something in the commit log about the efuse value. What 
is it, why does it appear etc.

Because just to be difficult you are not doing a 1:1 switch to hw_mode 
here, you're also introducing contingent logic.

---
bod

Re: [PATCH 2/7] of: factor out of_map_id() code

[Vijayanand Jitta]

On 2/2/2026 8:22 PM, Bryan O'Donoghue wrote:
> On 26/01/2026 12:25, Vikash Garodia wrote:
>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> 
> This commit message is confusing and inaccurate.
> 
> First up, you're not factoring _out_ of_map_id() - factor out of_map_id() means to remove of_map_id() - you are refactoring of_map_id().
> 
> Your patch title should be something like "refactor of_map_id() to prepare for mapping of multiple IDs to a single device"
> 

Sure, will update the commit.

>> Linux interprets multiple mappings for the same input ID as a set of
>> equivalent choices to pick one. There exists usecases where these set
>> must be maintained in parallel, ex: on ARM, a dynamically created child
>> device(s) is referencing multiple input id's in parent iommu-map.
>>
>> Factor out the code where multiple mappings needs to be maintained in
>> parallel can be achieved through callback from this factored out code.
> 
> Which callback ? There is no ->function(pointer, here...); ?!
> 
> Just make some plain and straightforward statements about what you are doing and why. There's no need to resort to dissertation-speak.
> 

The callback in introduced in patch 2 of this series. will update the commit descripition as suggested.

Thanks,
Vijay
>> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   drivers/of/base.c | 47 ++++++++++++++++++++++++++++++++---------------
>>   1 file changed, 32 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 0825f3dc93f2472e9947af09acdde72031ab85bc..606bef4f90e7d13bae4f7b0c45acd1755ad89826 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -2122,6 +2122,32 @@ static bool of_check_bad_map(const __be32 *map, int len)
>>       return true;
>>   }
>>   +static int of_map_id_fill_output(struct of_map_id_arg *arg,
>> +                 struct device_node *phandle_node, u32 id_or_offset,
>> +                 const __be32 *out_base, u32 cells,
>> +                 bool bypass)
>> +{
>> +    if (bypass) {
>> +        arg->map_args.args[0] = id_or_offset;
>> +        return 0;
>> +    }
>> +
>> +    if (arg->map_args.np)
>> +        of_node_put(phandle_node);
>> +    else
>> +        arg->map_args.np = phandle_node;
>> +
>> +    if (arg->map_args.np != phandle_node)
>> +        return -EAGAIN;
>> +
>> +    for (int i = 0; i < cells; i++)
>> +        arg->map_args.args[i] = (id_or_offset + be32_to_cpu(out_base[i]));
>> +
>> +    arg->map_args.args_count = cells;
>> +
>> +    return 0;
>> +}
>> +
>>   /**
>>    * of_map_id - Translate an ID through a downstream mapping.
>>    * @np: root complex device node.
>> @@ -2162,8 +2188,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>           if (arg->map_args.np)
>>               return -ENODEV;
>>           /* Otherwise, no map implies no translation */
>> -        arg->map_args.args[0] = id;
>> -        return 0;
>> +        goto bypass_translation;
>>       }
>>         if (map_bytes % sizeof(*map))
>> @@ -2185,6 +2210,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>           struct device_node *phandle_node;
>>           u32 id_base, phandle, id_len, id_off, cells = 0;
>>           const __be32 *out_base;
>> +        int ret;
>>             if (map_len - offset < 2)
>>               goto err_map_len;
>> @@ -2238,19 +2264,10 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>           if (masked_id < id_base || id_off >= id_len)
>>               continue;
>>   -        if (arg->map_args.np)
>> -            of_node_put(phandle_node);
>> -        else
>> -            arg->map_args.np = phandle_node;
>> -
>> -        if (arg->map_args.np != phandle_node)
>> +        ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
>> +        if (ret == -EAGAIN)
>>               continue;
>>   -        for (int i = 0; i < cells; i++)
>> -            arg->map_args.args[i] = (id_off + be32_to_cpu(out_base[i]));
>> -
>> -        arg->map_args.args_count = cells;
>> -
>>           pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
>>               np, map_name, map_mask, id_base, be32_to_cpup(out_base),
>>               id_len, id, id_off + be32_to_cpup(out_base));
>> @@ -2260,9 +2277,9 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>       pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
>>           id, arg->map_args.np  ? arg->map_args.np : NULL);
>>   +bypass_translation:
>>       /* Bypasses translation */
>> -    arg->map_args.args[0] = id;
>> -    return 0;
>> +    return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
>>     err_map_len:
>>       pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
>>
> 

Re: [PATCH 3/7] of/iommu: add multi-map support

[Vijayanand Jitta]

On 2/2/2026 8:27 PM, Bryan O'Donoghue wrote:
> On 26/01/2026 12:25, Vikash Garodia wrote:
>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>
>> When multiple mappings are present for an input id, linux matches just
>> the first one. There is a usecase[1] where all the mappings are to be
>> maintained in parallel for an iommu-map entry of a same input id.
>>
>> Whether multi-map is needed is reported by the callers through the
>> callback function passed, which is called for every input id match.
>>
>> Since the requirement in the usecase[1] is for platform devices, not
>> sure if it is really clean to maintain this decision on the bus type at
>> the of_iommu layer or further to be from the respective
>> iommu_driver->impl_ops().
>>
>> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
>>
>> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   drivers/iommu/of_iommu.c | 36 ++++++++++++++++++++++++++++--------
>>   drivers/of/base.c        | 38 ++++++++++++++++++++++++++++----------
>>   include/linux/of.h       |  6 ++++++
>>   3 files changed, 62 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 768eaddf927b0700b2497b08ea21611b1a1b5688..067bb2298973671e1eaf01bb2ea52df3d2a52a44 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -16,6 +16,7 @@
>>   #include <linux/pci.h>
>>   #include <linux/slab.h>
>>   #include <linux/fsl/mc.h>
>> +#include <linux/platform_device.h>
>>     #include "iommu-priv.h"
>>   @@ -41,22 +42,41 @@ static int of_iommu_xlate(struct device *dev,
>>       return ret;
>>   }
>>   +/*
>> + * Callback to be called from of_map_id(), that tells if
>> + * all the mappings for an input id to be maintained in
>> + * parallel. Should this decission be from further layers,
>> + * iommu_driver->impl_ops?
>> + */
>> +static int of_iommu_configure_cb(struct of_map_id_arg *arg)
>> +{
>> +    struct of_phandle_args *iommu_spec = &arg->map_args;
>> +    struct device *dev = arg->dev;
>> +    int err;
>> +
>> +    err = of_iommu_xlate(dev, iommu_spec);
>> +    of_node_put(iommu_spec->np);
>> +
>> +    /* !iommu_spec->np may be from the bypassed translations */
>> +    if (!err)
>> +        err = (!arg->multi_map || !iommu_spec->np) ? 0 : -EAGAIN;
>> +
>> +    return err;
>> +}
>> +
>>   static int of_iommu_configure_dev_id(struct device_node *master_np,
>>                        struct device *dev,
>>                        const u32 *id)
>>   {
>>       struct of_map_id_arg arg = {
>>           .map_args = {},
>> +        .cb = of_iommu_configure_cb,
>> +        .dev = dev,
>> +        /* Should this be pushed to iommu_driver->impl_ops? */
>> +        .multi_map = dev_is_platform(dev),
>>       };
>> -    int err;
>> -
>> -    err = of_map_iommu_id(master_np, *id, &arg);
>> -    if (err)
>> -        return err;
>>   -    err = of_iommu_xlate(dev, &arg.map_args);
>> -    of_node_put(arg.map_args.np);
>> -    return err;
>> +    return of_map_iommu_id(master_np, *id, &arg);
>>   }
>>     static int of_iommu_configure_dev(struct device_node *master_np,
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 606bef4f90e7d13bae4f7b0c45acd1755ad89826..a1c3c5954ec7e8eb3753c8fd782a1570f9eb9c17 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -2122,14 +2122,21 @@ static bool of_check_bad_map(const __be32 *map, int len)
>>       return true;
>>   }
>>   -static int of_map_id_fill_output(struct of_map_id_arg *arg,
>> -                 struct device_node *phandle_node, u32 id_or_offset,
>> -                 const __be32 *out_base, u32 cells,
>> -                 bool bypass)
>> +/*
>> + * Fill the id_out and target for the of_map_id() caller. Also
>> + * call the callback passed to the of_map_id() as part of the arg
>> + * that decides if to continue further search.
>> + */
>> +static int of_map_id_fill_arg(struct of_map_id_arg *arg,
>> +                  struct device_node *phandle_node, u32 id_or_offset,
>> +                  const __be32 *out_base, u32 cells,
>> +                  bool bypass, bool *multi_id_map)
>>   {
>> +    int ret;
>> +
>>       if (bypass) {
>>           arg->map_args.args[0] = id_or_offset;
>> -        return 0;
>> +        goto output;
>>       }
>>         if (arg->map_args.np)
>> @@ -2145,7 +2152,14 @@ static int of_map_id_fill_output(struct of_map_id_arg *arg,
>>         arg->map_args.args_count = cells;
>>   -    return 0;
>> +output:
>> +    /* pass the output for the callback, callers may further decide */
>> +    ret =  arg->cb ? arg->cb(arg) : 0;
>> +
>> +    if (multi_id_map && ret == -EAGAIN)
>> +        *multi_id_map = true;
>> +
>> +    return ret;
>>   }
>>     /**
>> @@ -2179,6 +2193,7 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>       int map_bytes, map_len, offset = 0;
>>       bool bad_map = false;
>>       const __be32 *map = NULL;
>> +    bool multi_id_map = false;
>>         if (!np || !map_name || !arg)
>>           return -EINVAL;
>> @@ -2264,23 +2279,26 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name,
>>           if (masked_id < id_base || id_off >= id_len)
>>               continue;
>>   -        ret = of_map_id_fill_output(arg, phandle_node, id_off, out_base, cells, false);
>> +        ret = of_map_id_fill_arg(arg, phandle_node, id_off, out_base,
>> +                     cells, false, &multi_id_map);
>>           if (ret == -EAGAIN)
>>               continue;
>>             pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
>>               np, map_name, map_mask, id_base, be32_to_cpup(out_base),
>>               id_len, id, id_off + be32_to_cpup(out_base));
>> -        return 0;
>> +        return ret;
>>       }
>>   +    if (multi_id_map)
>> +        return 0;
>> +
>>       pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
>>           id, arg->map_args.np  ? arg->map_args.np : NULL);
>>     bypass_translation:
>>       /* Bypasses translation */
>> -    return of_map_id_fill_output(arg, NULL, id, 0, 0, true);
>> -
>> +    return of_map_id_fill_arg(arg, NULL, id, 0, 0, true, NULL);
>>   err_map_len:
>>       pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
>>       return -EINVAL;
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index 9efa6f93712c6024f05476f9fd39f3294f942ec1..abab73a76682351f5635c1127a6c899917525050 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -25,6 +25,9 @@
>>   typedef u32 phandle;
>>   typedef u32 ihandle;
>>   +struct of_map_id_arg;
>> +typedef int (*of_map_id_cb)(struct of_map_id_arg *arg);
>> +
>>   struct property {
>>       char    *name;
>>       int    length;
>> @@ -76,6 +79,9 @@ struct of_phandle_args {
>>     struct of_map_id_arg {
>>       struct of_phandle_args map_args;
>> +    of_map_id_cb cb;
>> +    struct device *dev;
>> +    bool multi_map;
>>   };
>>     struct of_phandle_iterator {
>>
> 
> I think at a minimum this and the previous patch should be separated into its/their own series ∵ you really require this to be applied before proceeding on with the rest of the submission.
> 
> Get these two patches through iommu@lists.linux.dev in isolation and then submit the driver changes to consume.
> 
> ---
> bod

Sure, I’ll split the first two patches into a seperate series and submit them.

Thanks,
Vijay

Re: [PATCH 2/7] of: factor out of_map_id() code

[Dmitry Baryshkov]

On Tue, Feb 03, 2026 at 03:43:58PM +0530, Vijayanand Jitta wrote:
> 
> 
> On 2/2/2026 8:22 PM, Bryan O'Donoghue wrote:
> > On 26/01/2026 12:25, Vikash Garodia wrote:
> >> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> > 
> > This commit message is confusing and inaccurate.
> > 
> > First up, you're not factoring _out_ of_map_id() - factor out of_map_id() means to remove of_map_id() - you are refactoring of_map_id().
> > 
> > Your patch title should be something like "refactor of_map_id() to prepare for mapping of multiple IDs to a single device"
> > 
> 
> Sure, will update the commit.
> 
> >> Linux interprets multiple mappings for the same input ID as a set of
> >> equivalent choices to pick one. There exists usecases where these set
> >> must be maintained in parallel, ex: on ARM, a dynamically created child
> >> device(s) is referencing multiple input id's in parent iommu-map.
> >>
> >> Factor out the code where multiple mappings needs to be maintained in
> >> parallel can be achieved through callback from this factored out code.
> > 
> > Which callback ? There is no ->function(pointer, here...); ?!
> > 
> > Just make some plain and straightforward statements about what you are doing and why. There's no need to resort to dissertation-speak.
> > 
> 
> The callback in introduced in patch 2 of this series. will update the commit descripition as suggested.

I think, the callback was NAKed already.


-- 
With best wishes
Dmitry

Re: [PATCH 2/7] of: factor out of_map_id() code

[Vijayanand Jitta]

On 2/4/2026 6:41 AM, Dmitry Baryshkov wrote:
> On Tue, Feb 03, 2026 at 03:43:58PM +0530, Vijayanand Jitta wrote:
>>
>>
>> On 2/2/2026 8:22 PM, Bryan O'Donoghue wrote:
>>> On 26/01/2026 12:25, Vikash Garodia wrote:
>>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>>
>>> This commit message is confusing and inaccurate.
>>>
>>> First up, you're not factoring _out_ of_map_id() - factor out of_map_id() means to remove of_map_id() - you are refactoring of_map_id().
>>>
>>> Your patch title should be something like "refactor of_map_id() to prepare for mapping of multiple IDs to a single device"
>>>
>>
>> Sure, will update the commit.
>>
>>>> Linux interprets multiple mappings for the same input ID as a set of
>>>> equivalent choices to pick one. There exists usecases where these set
>>>> must be maintained in parallel, ex: on ARM, a dynamically created child
>>>> device(s) is referencing multiple input id's in parent iommu-map.
>>>>
>>>> Factor out the code where multiple mappings needs to be maintained in
>>>> parallel can be achieved through callback from this factored out code.
>>>
>>> Which callback ? There is no ->function(pointer, here...); ?!
>>>
>>> Just make some plain and straightforward statements about what you are doing and why. There's no need to resort to dissertation-speak.
>>>
>>
>> The callback in introduced in patch 2 of this series. will update the commit descripition as suggested.
> 
> I think, the callback was NAKed already.
> 
> 

I'll remove the callback and update change such that all entries of iommu-map are always scanned.
This would handle the video usecase ( i.e; same input id's mapping to different SIDs ) and in other
cases it would result in few additional scans in iommu-map compared to existing implementation (where
it just returns after first input id match) , does this look fine ?

Thanks,
Vijay

Re: [PATCH 2/7] of: factor out of_map_id() code

[Dmitry Baryshkov]

On Thu, Feb 05, 2026 at 01:39:54PM +0530, Vijayanand Jitta wrote:
> 
> 
> On 2/4/2026 6:41 AM, Dmitry Baryshkov wrote:
> > On Tue, Feb 03, 2026 at 03:43:58PM +0530, Vijayanand Jitta wrote:
> >>
> >>
> >> On 2/2/2026 8:22 PM, Bryan O'Donoghue wrote:
> >>> On 26/01/2026 12:25, Vikash Garodia wrote:
> >>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> >>>
> >>> This commit message is confusing and inaccurate.
> >>>
> >>> First up, you're not factoring _out_ of_map_id() - factor out of_map_id() means to remove of_map_id() - you are refactoring of_map_id().
> >>>
> >>> Your patch title should be something like "refactor of_map_id() to prepare for mapping of multiple IDs to a single device"
> >>>
> >>
> >> Sure, will update the commit.
> >>
> >>>> Linux interprets multiple mappings for the same input ID as a set of
> >>>> equivalent choices to pick one. There exists usecases where these set
> >>>> must be maintained in parallel, ex: on ARM, a dynamically created child
> >>>> device(s) is referencing multiple input id's in parent iommu-map.
> >>>>
> >>>> Factor out the code where multiple mappings needs to be maintained in
> >>>> parallel can be achieved through callback from this factored out code.
> >>>
> >>> Which callback ? There is no ->function(pointer, here...); ?!
> >>>
> >>> Just make some plain and straightforward statements about what you are doing and why. There's no need to resort to dissertation-speak.
> >>>
> >>
> >> The callback in introduced in patch 2 of this series. will update the commit descripition as suggested.
> > 
> > I think, the callback was NAKed already.
> > 
> > 
> 
> I'll remove the callback and update change such that all entries of iommu-map are always scanned.
> This would handle the video usecase ( i.e; same input id's mapping to different SIDs ) and in other
> cases it would result in few additional scans in iommu-map compared to existing implementation (where
> it just returns after first input id match) , does this look fine ?

This probably means that we can also drop of_map_args.

-- 
With best wishes
Dmitry

Re: [PATCH 3/7] of/iommu: add multi-map support

[Vikash Garodia]

On 1/27/2026 7:50 PM, Robin Murphy wrote:
> On 2026-01-27 11:45 am, Dmitry Baryshkov wrote:
>> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>>
>>> When multiple mappings are present for an input id, linux matches just
>>> the first one. There is a usecase[1] where all the mappings are to be
>>> maintained in parallel for an iommu-map entry of a same input id.
>>
>> This contradicts the IOMMU idealogy (at least as far as I understood it
>> fom the maintainers): the device (driver) doesn't control which IOMMUs
>> are getting used. Instead _all_ defined entries should get used. For
>> iommu-map it means that if the map defines several entries for a single
>> function, then all entries should always get mapped.
> 
> Indeed there is no concept of "multi-map" - if a single input ID 
> represents more than one thing then that notion of "input ID" is 
> fundamentally wrong. A single *device* may have multiple IDs, as in the 
> case of PCI bridge aliasing, but in that case there are multiple things 
> to map.

Let me take examples of kaanapali and sm8550 and describe the vpu stream 
id generation part,

kaanapali:
iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
             <0x100 &apps_smmu 0x1a20 0x0 0x1>,
             ....

sm8550:
iommus = <&apps_smmu 0x1940 0>,
	 <&apps_smmu 0x1947 0>;

In kaanapali, 0x1940 and 0x1a20 are the *resultant* stream-IDs. The 
resultant stream-id is generated based on
c-SID --> generated by vpu hardware, controlled by video firmware 
programming.
Topo ID --> port id, port at which vpu is connected to NOC, decided by 
vpu hardware.
TBU - smmu translation buffer unit, decided at soc design time.

Now if we take 0x1940 and 0x1a20, c-SID is same i.e 0. Within VPU, we 
have video engine (vcodec) and processor, both have different TOPO ID in 
kaanapali, whereas in sm8550, both have same TOPO ID. So vcodec and 
processor may (sm8550) or may not (kaanapali) have same stream-id.

There are some buffers, like internal buffers, are accessed by both, 
which then need both the stream-ids to be mapped into single context bank.

If you see sm8550, the requirement for both those hardware to access 
internal buffer is still there, since they have same c-SID, same topo id 
and tbu id, they have same stream id (0x1940)

Regards,
Vikash
> 
> Thanks,
> Robin.

Re: [PATCH 5/7] media: iris: add context bank devices using iommu-map

[Vikash Garodia]

On 1/27/2026 8:19 PM, Robin Murphy wrote:
> On 2026-01-26 12:25 pm, Vikash Garodia wrote:
>> Introduce different context banks(CB) and the associated buffer region.
>> Different stream IDs from VPU would be associated to one of these CB.
>> The patch ensures to handle CBs which are described as iommu-map in DT.
>> Multiple CBs are needed to increase the IOVA for the video usecases like
>> higher concurrent sessions.
>>
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   .../platform/qcom/iris/iris_platform_common.h      | 29 ++++++++++++
>>   drivers/media/platform/qcom/iris/iris_probe.c      | 55 ++++++++++++ 
>> ++++++++--
>>   drivers/media/platform/qcom/iris/iris_resources.c  | 35 ++++++++++++++
>>   drivers/media/platform/qcom/iris/iris_resources.h  |  1 +
>>   4 files changed, 116 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h 
>> b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 
>> 5a489917580eb10022fdcb52f7321a915e8b239d..d2d7c898fc8ef0de1b16aebd72681ea3c5b736ae 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -204,6 +204,33 @@ struct icc_vote_data {
>>       u32 fps;
>>   };
>> +enum iris_iommu_map_function_id {
>> +    IRIS_CB_NON_SECURE_NON_PIXEL    = 0x100,
>> +    IRIS_CB_NON_SECURE_PIXEL    = 0x101,
>> +    IRIS_CB_NON_SECURE_BITSTREAM    = 0x102,
>> +    IRIS_CB_SECURE_NON_PIXEL    = 0x200,
>> +    IRIS_CB_SECURE_PIXEL        = 0x201,
>> +    IRIS_CB_SECURE_BITSTREAM    = 0x202,
>> +    IRIS_CB_FIRMWARE        = 0x300,
>> +};
>> +
>> +enum iris_buffer_region {
>> +    IRIS_NON_SECURE_NON_PIXEL    = BIT(0),
>> +    IRIS_NON_SECURE_PIXEL        = BIT(1),
>> +    IRIS_NON_SECURE_BITSTREAM    = BIT(2),
>> +    IRIS_SECURE_NON_PIXEL        = BIT(3),
>> +    IRIS_SECURE_PIXEL        = BIT(4),
>> +    IRIS_SECURE_BITSTREAM        = BIT(5),
>> +};
>> +
>> +struct iris_context_bank {
>> +    struct device *dev;
>> +    const char *name;
>> +    const enum iris_iommu_map_function_id f_id;
>> +    const enum iris_buffer_region region;
>> +    const u64 dma_mask;
>> +};
>> +
>>   enum platform_pm_domain_type {
>>       IRIS_CTRL_POWER_DOMAIN,
>>       IRIS_HW_POWER_DOMAIN,
>> @@ -246,6 +273,8 @@ struct iris_platform_data {
>>       u32 inst_fw_caps_enc_size;
>>       const struct tz_cp_config *tz_cp_config_data;
>>       u32 tz_cp_config_data_size;
>> +    struct iris_context_bank *cb_data;
>> +    u32 cb_data_size;
>>       u32 core_arch;
>>       u32 hw_response_timeout;
>>       struct ubwc_config_data *ubwc_config;
>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/ 
>> media/platform/qcom/iris/iris_probe.c
>> index 
>> ddaacda523ecb9990af0dd0640196223fbcc2cab..c1a6aac5a3d65d980c5a34ba5fa1c1dbcf790ec5 100644
>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>> @@ -123,6 +123,37 @@ static int iris_init_resets(struct iris_core *core)
>>                        core->iris_platform_data- 
>> >controller_rst_tbl_size);
>>   }
>> +static int iris_init_context_bank_devices(struct iris_core *core)
>> +{
>> +    struct iris_context_bank *cb;
>> +    const __be32 *map_data;
>> +    int tupple_size = 5;
>> +    int i, j, ret, len;
>> +    u32 fid;
>> +
>> +    map_data = of_get_property(core->dev->of_node, "iommu-map", &len);
> 
> If despite proposing all this hackery in the common OF code you're then 
> _still_ going to open-code your own parsing of the property, with hard- 
> coded assumptions to boot, then clearly this is not the appropriate 
> approach at all...

Ack. Driver should not be doing the parsing which OF code is already 
doing it.

> 
>> +    if (!map_data)
>> +        return 0;
>> +
>> +    len /= sizeof(__be32);
>> +
>> +    for (i = 0; i < len; i += tupple_size) {
>> +        fid = be32_to_cpu(map_data[i]);
>> +
>> +        for (j = 0; j < core->iris_platform_data->cb_data_size; j++) {
>> +            cb = &core->iris_platform_data->cb_data[j];
>> +
>> +            if (fid == cb->f_id && !cb->dev) {
>> +                ret = iris_create_child_device_and_map(core, cb);
>> +                if (ret)
>> +                    return ret;
>> +            }
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>>   static int iris_init_resources(struct iris_core *core)
>>   {
>>       int ret;
>> @@ -139,7 +170,11 @@ static int iris_init_resources(struct iris_core 
>> *core)
>>       if (ret)
>>           return ret;
>> -    return iris_init_resets(core);
>> +    ret = iris_init_resets(core);
>> +    if (ret)
>> +        return ret;
>> +
>> +    return iris_init_context_bank_devices(core);
>>   }
>>   static int iris_register_video_device(struct iris_core *core, enum 
>> domain_type type)
>> @@ -187,6 +222,8 @@ static int iris_register_video_device(struct 
>> iris_core *core, enum domain_type t
>>   static void iris_remove(struct platform_device *pdev)
>>   {
>>       struct iris_core *core;
>> +    struct device *dev;
>> +    int i;
>>       core = platform_get_drvdata(pdev);
>>       if (!core)
>> @@ -194,6 +231,14 @@ static void iris_remove(struct platform_device 
>> *pdev)
>>       iris_core_deinit(core);
>> +    for (i = 0; i < core->iris_platform_data->cb_data_size; i++) {
>> +        dev = core->iris_platform_data->cb_data[i].dev;
>> +        if (dev) {
>> +            platform_device_unregister(to_platform_device(dev));
>> +            core->iris_platform_data->cb_data[i].dev = NULL;
>> +        }
>> +    }
>> +
>>       video_unregister_device(core->vdev_dec);
>>       video_unregister_device(core->vdev_enc);
>> @@ -277,9 +322,11 @@ static int iris_probe(struct platform_device *pdev)
>>       dma_mask = core->iris_platform_data->dma_mask;
>> -    ret = dma_set_mask_and_coherent(dev, dma_mask);
>> -    if (ret)
>> -        goto err_vdev_unreg_enc;
>> +    if (device_iommu_mapped(core->dev)) {
>> +        ret = dma_set_mask_and_coherent(core->dev, dma_mask);
> 
> Huh? Why would this be conditional? If it's a DMA device then it's a DMA 
> device, regardless of whether an IOMMU driver happens to be present or not.

To support existing SOC which are described by iommus, and not yet 
migrated to iommu-map.

> 
>> +        if (ret)
>> +            goto err_vdev_unreg_enc;
>> +    }
>>       dma_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
>>       dma_set_seg_boundary(&pdev->dev, DMA_BIT_MASK(32));
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/ 
>> drivers/media/platform/qcom/iris/iris_resources.c
>> index 
>> 773f6548370a257b8ae7332242544266cbbd61a9..647f6760f2b7a6bab8a585a13eb03cf60a9c047e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.c
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
>> @@ -6,6 +6,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/devfreq.h>
>>   #include <linux/interconnect.h>
>> +#include <linux/of_device.h>
>>   #include <linux/pm_domain.h>
>>   #include <linux/pm_opp.h>
>>   #include <linux/pm_runtime.h>
>> @@ -141,3 +142,37 @@ int iris_disable_unprepare_clock(struct iris_core 
>> *core, enum platform_clk_type
>>       return 0;
>>   }
>> +
>> +int iris_create_child_device_and_map(struct iris_core *core, struct 
>> iris_context_bank *cb)
>> +{
>> +    struct platform_device *pdev;
>> +    int ret;
>> +
>> +    pdev = platform_device_alloc(cb->name, 0);
>> +    if (!pdev)
>> +        return -ENOMEM;
>> +
>> +    ret = platform_device_add(pdev);
>> +    if (ret) {
>> +        platform_device_put(pdev);
>> +        return ret;
>> +    }
>> +
>> +    ret = of_dma_configure_id(&pdev->dev, core->dev->of_node, true,
>> +                  (const u32 *)&cb->f_id);
> 
> No. As I already said before, of_dma_configure() is for bus drivers; if 
> you want to act like a bus, implement a proper bus_type with 
> a .dma_configure callback. If you don't want to do that then describe 
> the individual functional blocks of the codec appropriately as distinct 
> devices with distinct hardware properties so the platform bus code can 
> handle them correctly. It is not reasonable to advertise physical 
> hardware to Linux as a single monolithic device, but then have a driver 
> try to pull a "well actually..." by abusing all the internal 
> abstractions. The fact that you might happen to avoid the warning from 
> iommu_probe_device() because you're not binding drivers to these fake 
> platform devices doesn't make this design any less wrong.

Ack. Agree to define a proper bus_type to handle the .dma_configure 
callback. Will update this in v2.

Regards,
Vikash
> 
> Thanks,
> Robin.
> 
>> +    if (ret)
>> +        goto error_unregister;
>> +
>> +    ret = dma_set_mask_and_coherent(&pdev->dev, cb->dma_mask);
>> +    if (ret)
>> +        goto error_unregister;
>> +
>> +    cb->dev = &pdev->dev;
>> +
>> +    return 0;
>> +
>> +error_unregister:
>> +    platform_device_unregister(to_platform_device(&pdev->dev));
>> +
>> +    return ret;
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/ 
>> drivers/media/platform/qcom/iris/iris_resources.h
>> index 
>> 6bfbd2dc6db095ec05e53c894e048285f82446c6..b7efe15facb203eea9ae13d5f0abdcc2ea718b4d 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.h
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.h
>> @@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
>>   int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
>>   int iris_disable_unprepare_clock(struct iris_core *core, enum 
>> platform_clk_type clk_type);
>>   int iris_prepare_enable_clock(struct iris_core *core, enum 
>> platform_clk_type clk_type);
>> +int iris_create_child_device_and_map(struct iris_core *core, struct 
>> iris_context_bank *cb);
>>   #endif
>>
> 

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Vikash Garodia]

On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>> compared to previous generation, iris3x, it has,
>> - separate power domains for stream and pixel processing hardware blocks
>>    (bse and vpp).
>> - additional power domain for apv codec.
>> - power domains for individual pipes (VPPx).
>> - different clocks and reset lines.
>>
>> iommu-map include all the different stream-ids which can be possibly
>> generated by vpu4 hardware.
> 
> It's not how it can be defined.

Do you mean to elaborate the different entries within iommu-map or to 
elaborate the different stream ids and how they are grouped into 
different functions ?

> 
>>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>>   1 file changed, 234 insertions(+)
>>
>> +
>> +  iommu-map: true
> 
> This is totally underspecifified.

oneof would be a better approach describing the possible stream-ids.

> 
>> +
>> +  memory-region:
>> +    maxItems: 1
>> +
> 
>> +
>> +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
>> +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
>> +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
>> +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
>> +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
>> +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
>> +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
>> +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
>> +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
> 
> #define the functions in the ABI, provide them in the bindings.

Ack. will introduce a new header at [1] and define these functions

[1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media

Regards,
Vikash

> 
>> +
> 

Re: [PATCH 4/7] media: iris: Switch to hardware mode after firmware boot

[Vikash Garodia]

On 2/2/2026 8:39 PM, Bryan O'Donoghue wrote:
> On 26/01/2026 12:25, Vikash Garodia wrote:
>> Currently the driver switches the vcodec GDSC to hardware (HW) mode
>> before firmware load and boot sequence. GDSC can be powered off,
>> keeping in hw mode, thereby the vcodec registers programmed in TrustZone
>> (TZ) carry default (reset) values.
>> Move the transition to HW mode after firmware load and boot sequence.
>>
>> The bug was exposed with driver configuring different stream ids to
>> different devices via iommu-map. With registers carrying reset values,
>> VPU would not generate desired stream-id, thereby leading to SMMU fault.
>>
>> Fixes: dde659d37036 ("media: iris: Introduce vpu ops for vpu4 with 
>> necessary hooks")
>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   drivers/media/platform/qcom/iris/iris_core.c       |  4 ++++
>>   drivers/media/platform/qcom/iris/iris_hfi_common.c |  4 ++++
>>   drivers/media/platform/qcom/iris/iris_vpu2.c       |  1 +
>>   drivers/media/platform/qcom/iris/iris_vpu3x.c      |  9 +++-----
>>   drivers/media/platform/qcom/iris/iris_vpu4x.c      | 24 +++++++++++ 
>> +----------
>>   drivers/media/platform/qcom/iris/iris_vpu_common.c | 16 +++++++++------
>>   drivers/media/platform/qcom/iris/iris_vpu_common.h |  3 +++
>>   7 files changed, 38 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_core.c b/drivers/ 
>> media/platform/qcom/iris/iris_core.c
>> index 
>> 8406c48d635b6eba0879396ce9f9ae2292743f09..dbaac01eb15a0e622e85635fddd29c1f7fc18662 100644
>> --- a/drivers/media/platform/qcom/iris/iris_core.c
>> +++ b/drivers/media/platform/qcom/iris/iris_core.c
>> @@ -75,6 +75,10 @@ int iris_core_init(struct iris_core *core)
>>       if (ret)
>>           goto error_unload_fw;
>>
>> +    ret = iris_vpu_switch_to_hwmode(core);
>> +    if (ret)
>> +        goto error_unload_fw;
>> +
>>       ret = iris_hfi_core_init(core);
>>       if (ret)
>>           goto error_unload_fw;
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.c b/ 
>> drivers/media/platform/qcom/iris/iris_hfi_common.c
>> index 
>> 92112eb16c11048e28230a2926dfb46e3163aada..621c66593d88d47ef3438c98a07cb29421c4e375 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_common.c
>> @@ -159,6 +159,10 @@ int iris_hfi_pm_resume(struct iris_core *core)
>>       if (ret)
>>           goto err_suspend_hw;
>>
>> +    ret = iris_vpu_switch_to_hwmode(core);
>> +    if (ret)
>> +        goto err_suspend_hw;
>> +
>>       ret = ops->sys_interframe_powercollapse(core);
>>       if (ret)
>>           goto err_suspend_hw;
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu2.c b/drivers/ 
>> media/platform/qcom/iris/iris_vpu2.c
>> index 
>> 9c103a2e4e4eafee101a8a9b168fdc8ca76e277d..01ef40f3895743b3784464e2d5ba2de1aeca5a4a 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu2.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu2.c
>> @@ -44,4 +44,5 @@ const struct vpu_ops iris_vpu2_ops = {
>>       .power_off_controller = iris_vpu_power_off_controller,
>>       .power_on_controller = iris_vpu_power_on_controller,
>>       .calc_freq = iris_vpu2_calc_freq,
>> +    .set_hwmode = iris_vpu_set_hwmode,
>>   };
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/ 
>> media/platform/qcom/iris/iris_vpu3x.c
>> index 
>> fe4423b951b1e9e31d06dffc69d18071cc985731..3dad47be78b58f6cd5ed6f333b3376571a04dbf0 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
>> @@ -234,14 +234,8 @@ static int iris_vpu35_power_on_hw(struct 
>> iris_core *core)
>>       if (ret)
>>           goto err_disable_hw_free_clk;
>>
>> -    ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl- 
>> >pd_devs[IRIS_HW_POWER_DOMAIN], true);
>> -    if (ret)
>> -        goto err_disable_hw_clk;
>> -
>>       return 0;
>>
>> -err_disable_hw_clk:
>> -    iris_disable_unprepare_clock(core, IRIS_HW_CLK);
>>   err_disable_hw_free_clk:
>>       iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
>>   err_disable_axi_clk:
>> @@ -266,6 +260,7 @@ const struct vpu_ops iris_vpu3_ops = {
>>       .power_off_controller = iris_vpu_power_off_controller,
>>       .power_on_controller = iris_vpu_power_on_controller,
>>       .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
>> +    .set_hwmode = iris_vpu_set_hwmode,
>>   };
>>
>>   const struct vpu_ops iris_vpu33_ops = {
>> @@ -274,6 +269,7 @@ const struct vpu_ops iris_vpu33_ops = {
>>       .power_off_controller = iris_vpu33_power_off_controller,
>>       .power_on_controller = iris_vpu_power_on_controller,
>>       .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
>> +    .set_hwmode = iris_vpu_set_hwmode,
>>   };
>>
>>   const struct vpu_ops iris_vpu35_ops = {
>> @@ -283,4 +279,5 @@ const struct vpu_ops iris_vpu35_ops = {
>>       .power_on_controller = iris_vpu35_vpu4x_power_on_controller,
>>       .program_bootup_registers = 
>> iris_vpu35_vpu4x_program_bootup_registers,
>>       .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
>> +    .set_hwmode = iris_vpu_set_hwmode,
>>   };
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/ 
>> media/platform/qcom/iris/iris_vpu4x.c
>> index 
>> a8db02ce5c5ec583c4027166b34ce51d3d683b4e..02e100a4045fced33d7a3545b632cc5f0955233f 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu4x.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
>> @@ -252,21 +252,10 @@ static int iris_vpu4x_power_on_hardware(struct 
>> iris_core *core)
>>           ret = iris_vpu4x_power_on_apv(core);
>>           if (ret)
>>               goto disable_hw_clocks;
>> -
>> -        iris_vpu4x_ahb_sync_reset_apv(core);
>>       }
>>
>> -    iris_vpu4x_ahb_sync_reset_hardware(core);
>> -
>> -    ret = iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
>> -    if (ret)
>> -        goto disable_apv_power_domain;
>> -
>>       return 0;
>>
>> -disable_apv_power_domain:
>> -    if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
>> -        iris_vpu4x_power_off_apv(core);
>>   disable_hw_clocks:
>>       iris_vpu4x_disable_hardware_clocks(core, efuse_value);
>>   disable_vpp1_power_domain:
>> @@ -359,6 +348,18 @@ static void iris_vpu4x_power_off_hardware(struct 
>> iris_core *core)
>>       iris_disable_power_domains(core, core->pmdomain_tbl- 
>> >pd_devs[IRIS_HW_POWER_DOMAIN]);
>>   }
>>
>> +static int iris_vpu4x_set_hwmode(struct iris_core *core)
>> +{
>> +    u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
>> +
>> +    if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
>> +        iris_vpu4x_ahb_sync_reset_apv(core);
>> +
>> +    iris_vpu4x_ahb_sync_reset_hardware(core);
>> +
>> +    return iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
> I'd like to see something in the commit log about the efuse value. What 
> is it, why does it appear etc.
> 
> Because just to be difficult you are not doing a 1:1 switch to hw_mode 
> here, you're also introducing contingent logic.
> 

The reset was added _only_ on vpu4 switching to hw mode as there is an 
issue of register corruption if ahb reset is not performed before mode 
switch. Hence reset is made explicitly part of hw mode switch.
Its there in earlier code "iris_vpu4x_power_on_hardware" as well, while 
this patch is shifting the code to a vpu specific hw mode api.

fuse check is only to differentiate between apv and others, since apv 
reset sequence is different than others.

I can add these info in commit.

Regards,
Vikash

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
> 
> On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
> > > Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> > > compared to previous generation, iris3x, it has,
> > > - separate power domains for stream and pixel processing hardware blocks
> > >    (bse and vpp).
> > > - additional power domain for apv codec.
> > > - power domains for individual pipes (VPPx).
> > > - different clocks and reset lines.
> > > 
> > > iommu-map include all the different stream-ids which can be possibly
> > > generated by vpu4 hardware.
> > 
> > It's not how it can be defined.
> 
> Do you mean to elaborate the different entries within iommu-map or to
> elaborate the different stream ids and how they are grouped into different
> functions ?

The comment was sent three weeks ago.

> 
> > 
> > > 
> > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > ---
> > >   .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
> > >   1 file changed, 234 insertions(+)
> > > 
> > > +
> > > +  iommu-map: true
> > 
> > This is totally underspecifified.
> 
> oneof would be a better approach describing the possible stream-ids.

oneOf of what? It is items with the definition of each item.

> 
> > 
> > > +
> > > +  memory-region:
> > > +    maxItems: 1
> > > +
> > 
> > > +
> > > +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
> > > +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
> > > +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
> > > +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
> > > +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
> > > +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
> > > +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
> > > +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
> > > +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
> > 
> > #define the functions in the ABI, provide them in the bindings.
> 
> Ack. will introduce a new header at [1] and define these functions
> 
> [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
> 
> Regards,
> Vikash
> 
> > 
> > > +
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Vikash Garodia]

On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
>>
>> On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
>>>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>>>> compared to previous generation, iris3x, it has,
>>>> - separate power domains for stream and pixel processing hardware blocks
>>>>     (bse and vpp).
>>>> - additional power domain for apv codec.
>>>> - power domains for individual pipes (VPPx).
>>>> - different clocks and reset lines.
>>>>
>>>> iommu-map include all the different stream-ids which can be possibly
>>>> generated by vpu4 hardware.
>>>
>>> It's not how it can be defined.
>>
>> Do you mean to elaborate the different entries within iommu-map or to
>> elaborate the different stream ids and how they are grouped into different
>> functions ?
> 
> The comment was sent three weeks ago.

yeah, if you could still recollect, you can comment.

> 
>>
>>>
>>>>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>>    .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>>>>    1 file changed, 234 insertions(+)
>>>>
>>>> +
>>>> +  iommu-map: true
>>>
>>> This is totally underspecifified.
>>
>> oneof would be a better approach describing the possible stream-ids.
> 
> oneOf of what? It is items with the definition of each item.

something like below,

properties:
   iommu-map:
     description: |
       List of IOMMU stream IDs corresponding to hardware function IDs.
       The number of entries depends on the SoC variant.
     type: array
     oneOf:
       - minItems: 8
         maxItems: 8
         items:
           type: integer
           description: IOMMU stream IDs

       - minItems: 9
         maxItems: 9
         items:
           type: integer
           description: IOMMU stream IDs
> 
>>
>>>
>>>> +
>>>> +  memory-region:
>>>> +    maxItems: 1
>>>> +
>>>
>>>> +
>>>> +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
>>>> +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
>>>> +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
>>>> +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
>>>> +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
>>>> +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
>>>> +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
>>>> +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
>>>> +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
>>>
>>> #define the functions in the ABI, provide them in the bindings.
>>
>> Ack. will introduce a new header at [1] and define these functions
>>
>> [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
>>
>> Regards,
>> Vikash
>>
>>>
>>>> +
>>>
>>
> 

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 09:04:52PM +0530, Vikash Garodia wrote:
> 
> On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
> > On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
> > > 
> > > On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
> > > > > Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> > > > > compared to previous generation, iris3x, it has,
> > > > > - separate power domains for stream and pixel processing hardware blocks
> > > > >     (bse and vpp).
> > > > > - additional power domain for apv codec.
> > > > > - power domains for individual pipes (VPPx).
> > > > > - different clocks and reset lines.
> > > > > 
> > > > > iommu-map include all the different stream-ids which can be possibly
> > > > > generated by vpu4 hardware.
> > > > 
> > > > It's not how it can be defined.
> > > 
> > > Do you mean to elaborate the different entries within iommu-map or to
> > > elaborate the different stream ids and how they are grouped into different
> > > functions ?
> > 
> > The comment was sent three weeks ago.
> 
> yeah, if you could still recollect, you can comment.

I think it was more about 'stream IDs for pixel, secure, no-pixel,
firmware, buffers, non-buffers and direct insight into the VPU memory'
(pure example, as you can guess).

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > > > ---
> > > > >    .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
> > > > >    1 file changed, 234 insertions(+)
> > > > > 
> > > > > +
> > > > > +  iommu-map: true
> > > > 
> > > > This is totally underspecifified.
> > > 
> > > oneof would be a better approach describing the possible stream-ids.
> > 
> > oneOf of what? It is items with the definition of each item.
> 
> something like below,
> 
> properties:
>   iommu-map:
>     description: |
>       List of IOMMU stream IDs corresponding to hardware function IDs.
>       The number of entries depends on the SoC variant.

Do we again have a story of variable number of entries for the single
Kaanapali platform?

>     type: array
>     oneOf:
>       - minItems: 8
>         maxItems: 8
>         items:
>           type: integer
>           description: IOMMU stream IDs
> 
>       - minItems: 9
>         maxItems: 9
>         items:
>           type: integer
>           description: IOMMU stream IDs
> > 
> > > 
> > > > 
> > > > > +
> > > > > +  memory-region:
> > > > > +    maxItems: 1
> > > > > +
> > > > 
> > > > > +
> > > > > +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
> > > > > +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
> > > > > +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
> > > > > +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
> > > > > +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
> > > > > +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
> > > > > +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
> > > > > +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
> > > > > +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
> > > > 
> > > > #define the functions in the ABI, provide them in the bindings.
> > > 
> > > Ack. will introduce a new header at [1] and define these functions
> > > 
> > > [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
> > > 
> > > Regards,
> > > Vikash
> > > 
> > > > 
> > > > > +
> > > > 
> > > 
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Krzysztof Kozlowski]

On 17/02/2026 16:34, Vikash Garodia wrote:
> 
> On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
>> On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
>>>
>>> On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
>>>> On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
>>>>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>>>>> compared to previous generation, iris3x, it has,
>>>>> - separate power domains for stream and pixel processing hardware blocks
>>>>>     (bse and vpp).
>>>>> - additional power domain for apv codec.
>>>>> - power domains for individual pipes (VPPx).
>>>>> - different clocks and reset lines.
>>>>>
>>>>> iommu-map include all the different stream-ids which can be possibly
>>>>> generated by vpu4 hardware.
>>>>
>>>> It's not how it can be defined.
>>>
>>> Do you mean to elaborate the different entries within iommu-map or to
>>> elaborate the different stream ids and how they are grouped into different
>>> functions ?
>>
>> The comment was sent three weeks ago.
> 
> yeah, if you could still recollect, you can comment.
> 
>>
>>>
>>>>
>>>>>
>>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>>> ---
>>>>>    .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>>>>>    1 file changed, 234 insertions(+)
>>>>>
>>>>> +
>>>>> +  iommu-map: true
>>>>
>>>> This is totally underspecifified.
>>>
>>> oneof would be a better approach describing the possible stream-ids.
>>
>> oneOf of what? It is items with the definition of each item.
> 
> something like below,
> 
> properties:
>    iommu-map:
>      description: |
>        List of IOMMU stream IDs corresponding to hardware function IDs.
>        The number of entries depends on the SoC variant.
>      type: array
>      oneOf:
>        - minItems: 8
>          maxItems: 8
>          items:
>            type: integer
>            description: IOMMU stream IDs
> 
>        - minItems: 9
>          maxItems: 9
>          items:
>            type: integer
>            description: IOMMU stream IDs


This gives no useful description. Can it be something else than IOMMU
stream ID? No, it cannot. Saying then that this is stream ID is like
saying listing clocks and calling them "clock input".

This should be list of descriptions explaining their function/purpose or
whatever region is there mapped.

Best regards,
Krzysztof

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Vikash Garodia]

On 2/17/2026 9:45 PM, Dmitry Baryshkov wrote:
> On Tue, Feb 17, 2026 at 09:04:52PM +0530, Vikash Garodia wrote:
>>
>> On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
>>> On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
>>>>
>>>> On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
>>>>>> Kaanapali SOC brings in the new generation of video IP i.e iris4. When
>>>>>> compared to previous generation, iris3x, it has,
>>>>>> - separate power domains for stream and pixel processing hardware blocks
>>>>>>      (bse and vpp).
>>>>>> - additional power domain for apv codec.
>>>>>> - power domains for individual pipes (VPPx).
>>>>>> - different clocks and reset lines.
>>>>>>
>>>>>> iommu-map include all the different stream-ids which can be possibly
>>>>>> generated by vpu4 hardware.
>>>>>
>>>>> It's not how it can be defined.
>>>>
>>>> Do you mean to elaborate the different entries within iommu-map or to
>>>> elaborate the different stream ids and how they are grouped into different
>>>> functions ?
>>>
>>> The comment was sent three weeks ago.
>>
>> yeah, if you could still recollect, you can comment.
> 
> I think it was more about 'stream IDs for pixel, secure, no-pixel,
> firmware, buffers, non-buffers and direct insight into the VPU memory'
> (pure example, as you can guess).
> 
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>>>> ---
>>>>>>     .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
>>>>>>     1 file changed, 234 insertions(+)
>>>>>>
>>>>>> +
>>>>>> +  iommu-map: true
>>>>>
>>>>> This is totally underspecifified.
>>>>
>>>> oneof would be a better approach describing the possible stream-ids.
>>>
>>> oneOf of what? It is items with the definition of each item.
>>
>> something like below,
>>
>> properties:
>>    iommu-map:
>>      description: |
>>        List of IOMMU stream IDs corresponding to hardware function IDs.
>>        The number of entries depends on the SoC variant.
> 
> Do we again have a story of variable number of entries for the single
> Kaanapali platform?

its for firmware stream-ID, which can be managed by kernel or Gunyah. 
Handling for it now would ensure we do not have to change the binding 
later when there is a need.

> 
>>      type: array
>>      oneOf:
>>        - minItems: 8
>>          maxItems: 8
>>          items:
>>            type: integer
>>            description: IOMMU stream IDs
>>
>>        - minItems: 9
>>          maxItems: 9
>>          items:
>>            type: integer
>>            description: IOMMU stream IDs
>>>
>>>>
>>>>>
>>>>>> +
>>>>>> +  memory-region:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>
>>>>>> +
>>>>>> +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
>>>>>> +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
>>>>>> +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
>>>>>> +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
>>>>>> +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
>>>>>> +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
>>>>>> +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
>>>>>> +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
>>>>>> +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
>>>>>
>>>>> #define the functions in the ABI, provide them in the bindings.
>>>>
>>>> Ack. will introduce a new header at [1] and define these functions
>>>>
>>>> [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
>>>>
>>>> Regards,
>>>> Vikash
>>>>
>>>>>
>>>>>> +
>>>>>
>>>>
>>>
>>
> 

Re: [PATCH 1/7] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

[Dmitry Baryshkov]

On Tue, Feb 17, 2026 at 11:39:53PM +0530, Vikash Garodia wrote:
> 
> On 2/17/2026 9:45 PM, Dmitry Baryshkov wrote:
> > On Tue, Feb 17, 2026 at 09:04:52PM +0530, Vikash Garodia wrote:
> > > 
> > > On 2/17/2026 8:06 PM, Dmitry Baryshkov wrote:
> > > > On Tue, Feb 17, 2026 at 07:13:39PM +0530, Vikash Garodia wrote:
> > > > > 
> > > > > On 1/27/2026 8:39 PM, Dmitry Baryshkov wrote:
> > > > > > On Mon, Jan 26, 2026 at 05:55:44PM +0530, Vikash Garodia wrote:
> > > > > > > Kaanapali SOC brings in the new generation of video IP i.e iris4. When
> > > > > > > compared to previous generation, iris3x, it has,
> > > > > > > - separate power domains for stream and pixel processing hardware blocks
> > > > > > >      (bse and vpp).
> > > > > > > - additional power domain for apv codec.
> > > > > > > - power domains for individual pipes (VPPx).
> > > > > > > - different clocks and reset lines.
> > > > > > > 
> > > > > > > iommu-map include all the different stream-ids which can be possibly
> > > > > > > generated by vpu4 hardware.
> > > > > > 
> > > > > > It's not how it can be defined.
> > > > > 
> > > > > Do you mean to elaborate the different entries within iommu-map or to
> > > > > elaborate the different stream ids and how they are grouped into different
> > > > > functions ?
> > > > 
> > > > The comment was sent three weeks ago.
> > > 
> > > yeah, if you could still recollect, you can comment.
> > 
> > I think it was more about 'stream IDs for pixel, secure, no-pixel,
> > firmware, buffers, non-buffers and direct insight into the VPU memory'
> > (pure example, as you can guess).
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > > > > > ---
> > > > > > >     .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
> > > > > > >     1 file changed, 234 insertions(+)
> > > > > > > 
> > > > > > > +
> > > > > > > +  iommu-map: true
> > > > > > 
> > > > > > This is totally underspecifified.
> > > > > 
> > > > > oneof would be a better approach describing the possible stream-ids.
> > > > 
> > > > oneOf of what? It is items with the definition of each item.
> > > 
> > > something like below,
> > > 
> > > properties:
> > >    iommu-map:
> > >      description: |
> > >        List of IOMMU stream IDs corresponding to hardware function IDs.
> > >        The number of entries depends on the SoC variant.
> > 
> > Do we again have a story of variable number of entries for the single
> > Kaanapali platform?
> 
> its for firmware stream-ID, which can be managed by kernel or Gunyah.
> Handling for it now would ensure we do not have to change the binding later
> when there is a need.

In my humble opionion the firmware stream-ID should be there, but let
the driver detect whether to use it or not.

Another approach might be:

iommu-map:
  items:
    - foo
    - bar
    - baz
    - ....
    - firmware
  # firmware might be handled by the TZ / hyp
  minItems: 8


> 
> > 
> > >      type: array
> > >      oneOf:
> > >        - minItems: 8
> > >          maxItems: 8
> > >          items:
> > >            type: integer
> > >            description: IOMMU stream IDs
> > > 
> > >        - minItems: 9
> > >          maxItems: 9
> > >          items:
> > >            type: integer
> > >            description: IOMMU stream IDs
> > > > 
> > > > > 
> > > > > > 
> > > > > > > +
> > > > > > > +  memory-region:
> > > > > > > +    maxItems: 1
> > > > > > > +
> > > > > > 
> > > > > > > +
> > > > > > > +        iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
> > > > > > > +                    <0x100 &apps_smmu 0x1a20 0x0 0x1>,
> > > > > > > +                    <0x100 &apps_smmu 0x1944 0x0 0x1>,
> > > > > > > +                    <0x101 &apps_smmu 0x1943 0x0 0x1>,
> > > > > > > +                    <0x200 &apps_smmu 0x1941 0x0 0x1>,
> > > > > > > +                    <0x200 &apps_smmu 0x1a21 0x0 0x1>,
> > > > > > > +                    <0x201 &apps_smmu 0x1945 0x0 0x1>,
> > > > > > > +                    <0x202 &apps_smmu 0x1946 0x0 0x1>,
> > > > > > > +                    <0x300 &apps_smmu 0x1a22 0x0 0x1>;
> > > > > > 
> > > > > > #define the functions in the ABI, provide them in the bindings.
> > > > > 
> > > > > Ack. will introduce a new header at [1] and define these functions
> > > > > 
> > > > > [1] https://github.com/torvalds/linux/tree/master/include/dt-bindings/media
> > > > > 
> > > > > Regards,
> > > > > Vikash
> > > > > 
> > > > > > 
> > > > > > > +
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH 3/7] of/iommu: add multi-map support

[Vikash Garodia]

On 2/17/2026 6:38 PM, Vikash Garodia wrote:
> 
> On 1/27/2026 7:50 PM, Robin Murphy wrote:
>> On 2026-01-27 11:45 am, Dmitry Baryshkov wrote:
>>> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
>>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>>>
>>>> When multiple mappings are present for an input id, linux matches just
>>>> the first one. There is a usecase[1] where all the mappings are to be
>>>> maintained in parallel for an iommu-map entry of a same input id.
>>>
>>> This contradicts the IOMMU idealogy (at least as far as I understood it
>>> fom the maintainers): the device (driver) doesn't control which IOMMUs
>>> are getting used. Instead _all_ defined entries should get used. For
>>> iommu-map it means that if the map defines several entries for a single
>>> function, then all entries should always get mapped.
>>
>> Indeed there is no concept of "multi-map" - if a single input ID 
>> represents more than one thing then that notion of "input ID" is 
>> fundamentally wrong. A single *device* may have multiple IDs, as in 
>> the case of PCI bridge aliasing, but in that case there are multiple 
>> things to map.
> 
> Let me take examples of kaanapali and sm8550 and describe the vpu stream 
> id generation part,
> 
> kaanapali:
> iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
>              <0x100 &apps_smmu 0x1a20 0x0 0x1>,
>              ....
> 
> sm8550:
> iommus = <&apps_smmu 0x1940 0>,
>       <&apps_smmu 0x1947 0>;
> 
> In kaanapali, 0x1940 and 0x1a20 are the *resultant* stream-IDs. The 
> resultant stream-id is generated based on
> c-SID --> generated by vpu hardware, controlled by video firmware 
> programming.
> Topo ID --> port id, port at which vpu is connected to NOC, decided by 
> vpu hardware.
> TBU - smmu translation buffer unit, decided at soc design time.
> 
> Now if we take 0x1940 and 0x1a20, c-SID is same i.e 0. Within VPU, we 
> have video engine (vcodec) and processor, both have different TOPO ID in 
> kaanapali, whereas in sm8550, both have same TOPO ID. So vcodec and 
> processor may (sm8550) or may not (kaanapali) have same stream-id.
> 
> There are some buffers, like internal buffers, are accessed by both, 
> which then need both the stream-ids to be mapped into single context bank.
> 
> If you see sm8550, the requirement for both those hardware to access 
> internal buffer is still there, since they have same c-SID, same topo id 
> and tbu id, they have same stream id (0x1940)

Robin,

do you have any further comments on this ?

> 
> Regards,
> Vikash
>>
>> Thanks,
>> Robin.
>