[RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[Vikash Garodia]

VPU hardwares have a limitation where VPU streams are associated with
dedicated addressable address range, as illustrated below

    +-----------------------------------------------------------+
    | Stream A reserved region (600 MB)                         |
    | 0x00000000 - 0x25800000                                   |
    +-----------------------------------------------------------+
    | Stream B reserved region (3.5 GB)                         |
    | 0x00000000 - 0xe0000000                                   |
    +-----------------------------------------------------------+
    | Other reserved regions                                    |
    +-----------------------------------------------------------+

Mapping a stream outside its expected range can cause unintended 
behavior, including device crashes, as reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Daniel, who reported the crash issue, have also raised a patch to workaround
the issue. While the patch partially handles the limitation, it is inefficient
in a way that it keep iris hardwares away from using the 600MB address space
for all the different streams.

To address this limitation, the subset of stream/s are now represented as
sub nodes, so that they can be associated to the respective addressable
range.
In the past, this limitation was tried with iommu-map approach, with iris
driver dynamically creating the devices. The approach was later concluded
as an hack to avoid having sub nodes. It was discussed in detail in the
discussion https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/

It was agreed by maintainers to proceed with sub node approach to address
the VPU hardware limitation.

Sending this series as an RFC as i am unsure on handling of address 
and size cells. While parsing the iommu-addresses, device parent should 
have the address and size cell, thereby added the same in parent node 
i.e iris in this case. Kernel mandates this, otherwise emits below. 
Keeping them in iris (parent device) meets the kernel ask.

[    6.953615] Missing '#address-cells' in /soc@0/video-codec@aa00000
[    6.968288] WARNING: drivers/of/base.c:115 at of_bus_n_addr_cells+0xa4/0xf4

[    7.440909] Missing '#size-cells' in /soc@0/video-codec@aa00000
[    7.447044] WARNING: drivers/of/base.c:142 at of_bus_n_size_cells+0xa4/0xf8

Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Vikash Garodia (11):
      dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes
      media: iris: Add hooks to initialize and tear down context banks
      media: iris: Add helper to create a context bank device
      media: iris: Add helper to select relevant context bank device
      media: iris: Skip DMA mask setting to core device when IOMMU is not mapped
      media: iris: Add hooks for pixel and non-pixel context banks
      arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
      arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes
      arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes
      arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes
      arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

 .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++-
 arch/arm64/boot/dts/qcom/hamoa.dtsi                | 18 +++++-
 arch/arm64/boot/dts/qcom/lemans.dtsi               | 18 +++++-
 arch/arm64/boot/dts/qcom/monaco.dtsi               | 18 +++++-
 arch/arm64/boot/dts/qcom/qcs8550.dtsi              |  4 ++
 arch/arm64/boot/dts/qcom/sm8550.dtsi               | 18 +++++-
 arch/arm64/boot/dts/qcom/sm8650.dtsi               | 19 +++++-
 drivers/media/platform/qcom/iris/Makefile          |  1 +
 drivers/media/platform/qcom/iris/iris_buffer.c     |  8 +--
 drivers/media/platform/qcom/iris/iris_core.h       |  4 ++
 drivers/media/platform/qcom/iris/iris_hfi_queue.c  | 16 ++---
 .../platform/qcom/iris/iris_platform_common.h      |  6 ++
 .../platform/qcom/iris/iris_platform_sm8550.c      | 71 ++++++++++++++++++++++
 .../platform/qcom/iris/iris_platform_sm8550.h      | 24 ++------
 .../media/platform/qcom/iris/iris_platform_vpu3x.c |  4 ++
 drivers/media/platform/qcom/iris/iris_probe.c      | 32 ++++++++--
 drivers/media/platform/qcom/iris/iris_resources.c  | 64 +++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_resources.h  |  2 +
 drivers/media/platform/qcom/iris/iris_vidc.c       |  4 +-
 19 files changed, 346 insertions(+), 51 deletions(-)
---
base-commit: b9810cd75b9fb56a3425d391cba3f608502bd474
change-id: 20260701-vpu_iommu_iova_handling-556e969a1f1c

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

[RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Vikash Garodia]

VPU hardwares have a limitation where VPU streams are associated with
dedicated addressable address range, as illustrated below

    +-----------------------------------------------------------+
    | Stream A reserved region (600 MB)                         |
    | 0x00000000 - 0x25800000                                   |
    +-----------------------------------------------------------+
    | Stream B reserved region (3.5 GB)                         |
    | 0x00000000 - 0xe0000000                                   |
    +-----------------------------------------------------------+
    | Other reserved regions                                    |
    +-----------------------------------------------------------+

Mapping a stream outside its expected range can cause unintended
behavior, including device crashes, as reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

To address this limitation, the subset of stream/s are now represented as
sub nodes, so that they can be associated to the respective addressable
range.
The limitation could be exposed when running usecase like concurrent
video sessions. The binding have been validated with higher concurrent
sessions across the SOCs supported under this schema.

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>
---
 .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
 1 file changed, 63 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -91,6 +91,51 @@ properties:
   opp-table:
     type: object
 
+  '#address-cells':
+    const: 2
+
+  '#size-cells':
+    const: 2
+
+  non-pixel:
+    type: object
+    description:
+      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
+      buffers. Non pixel buffers are compressed and internal buffers.
+    properties:
+      iommus:
+        maxItems: 1
+      memory-region:
+        maxItems: 1
+    required:
+      - iommus
+      - memory-region
+    additionalProperties: false
+
+  pixel:
+    type: object
+    description:
+      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
+      Pixel buffers are uncompressed buffers.
+    properties:
+      iommus:
+        maxItems: 1
+    required:
+      - iommus
+    additionalProperties: false
+
+  firmware:
+    type: object
+    description:
+      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
+      VPU when no hypervisor is present.
+    properties:
+      iommus:
+        maxItems: 1
+    required:
+      - iommus
+    additionalProperties: false
+
 required:
   - compatible
   - power-domain-names
@@ -98,9 +143,15 @@ required:
   - interconnect-names
   - resets
   - reset-names
-  - iommus
   - dma-coherent
 
+oneOf:
+  - required:
+      - iommus
+  - required:
+      - non-pixel
+      - pixel
+
 allOf:
   - if:
       properties:
@@ -177,12 +228,21 @@ examples:
         resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
         reset-names = "bus";
 
-        iommus = <&apps_smmu 0x1940 0x0000>,
-                 <&apps_smmu 0x1947 0x0000>;
         dma-coherent;
 
         operating-points-v2 = <&iris_opp_table>;
 
+        #address-cells = <2>;
+        #size-cells = <2>;
+        iris_non_pixel: non-pixel {
+            iommus = <&apps_smmu 0x1940 0x0000>;
+            memory-region = <&iris_resv>;
+        };
+
+        iris_pixel: pixel {
+            iommus = <&apps_smmu 0x1947 0x0000>;
+        };
+
         iris_opp_table: opp-table {
             compatible = "operating-points-v2";
 

-- 
2.34.1

[RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks

[Vikash Garodia]

Add platform hooks to set up and tear down context bank devices.
Different Iris platforms may require different context bank setup, so
let platform data provide the required operations.

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      |  6 ++++++
 drivers/media/platform/qcom/iris/iris_probe.c      | 24 +++++++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index c9256f2323dc4521f9eacaeffb0fc08a180de3ff..0d738005fbc3bc0f675165aea0bcf09943441a5d 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -288,6 +288,11 @@ struct iris_firmware_desc {
 	const char *fwname;
 };
 
+struct iris_context_bank_ops {
+	int (*init)(struct iris_core *core);
+	void (*deinit)(struct iris_core *core);
+};
+
 struct iris_platform_data {
 	/*
 	 * XXX: replace with gen1 / gen2 pointers once we have platforms
@@ -295,6 +300,7 @@ struct iris_platform_data {
 	 */
 	const struct iris_firmware_desc *firmware_desc;
 
+	const struct iris_context_bank_ops *cb_ops;
 	const struct vpu_ops *vpu_ops;
 	const struct icc_info *icc_tbl;
 	unsigned int icc_tbl_size;
diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index c2dcb50a27824d45d5fbc8b9e22591decbe2a23b..0bce4fb1786bc9371074cb72e082219ded4840e5 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -150,6 +150,20 @@ static int iris_init_resources(struct iris_core *core)
 	return iris_init_resets(core);
 }
 
+static int iris_init_cb_devs(struct iris_core *core)
+{
+	if (core->iris_platform_data->cb_ops)
+		return core->iris_platform_data->cb_ops->init(core);
+
+	return 0;
+}
+
+static void iris_deinit_cb_devs(struct iris_core *core)
+{
+	if (core->iris_platform_data->cb_ops)
+		core->iris_platform_data->cb_ops->deinit(core);
+}
+
 static int iris_register_video_device(struct iris_core *core, enum domain_type type)
 {
 	struct video_device *vdev;
@@ -207,6 +221,8 @@ static void iris_remove(struct platform_device *pdev)
 
 	v4l2_device_unregister(&core->v4l2_dev);
 
+	iris_deinit_cb_devs(core);
+
 	mutex_destroy(&core->lock);
 }
 
@@ -273,10 +289,14 @@ static int iris_probe(struct platform_device *pdev)
 
 	iris_session_init_caps(core);
 
-	ret = v4l2_device_register(dev, &core->v4l2_dev);
+	ret = iris_init_cb_devs(core);
 	if (ret)
 		return ret;
 
+	ret = v4l2_device_register(dev, &core->v4l2_dev);
+	if (ret)
+		goto err_cb_deinit;
+
 	ret = iris_register_video_device(core, DECODER);
 	if (ret)
 		goto err_v4l2_unreg;
@@ -310,6 +330,8 @@ static int iris_probe(struct platform_device *pdev)
 	video_unregister_device(core->vdev_dec);
 err_v4l2_unreg:
 	v4l2_device_unregister(&core->v4l2_dev);
+err_cb_deinit:
+	iris_deinit_cb_devs(core);
 
 	return ret;
 }

-- 
2.34.1

[RFC PATCH 03/11] media: iris: Add helper to create a context bank device

[Vikash Garodia]

The subnode in the device tree is registered as a separate device so
that it gets its own IOMMU context. Pixel/non-pixel buffers are mapped
into these iommu domain, to ensure they are within the addressable range.

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_resources.c | 23 +++++++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_resources.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
index 773f6548370a257b8ae7332242544266cbbd61a9..f550d194edf58abf0687a4f5df6d06b2af35147d 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -141,3 +141,26 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
 
 	return 0;
 }
+
+struct device *iris_create_cb_dev(struct iris_core *core, const char *name)
+{
+	struct platform_device_info plat_dev_info = {};
+	struct device_node *child_of_node;
+	struct platform_device *pdev;
+
+	child_of_node = of_get_child_by_name(core->dev->of_node, name);
+	if (!child_of_node)
+		return NULL;
+
+	plat_dev_info.dma_mask = core->iris_platform_data->dma_mask;
+	plat_dev_info.fwnode = &child_of_node->fwnode;
+	plat_dev_info.name = child_of_node->name;
+	plat_dev_info.parent = core->dev;
+
+	pdev = platform_device_register_full(&plat_dev_info);
+	of_node_put(child_of_node);
+	if (IS_ERR(pdev))
+		return ERR_CAST(pdev);
+
+	return &pdev->dev;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index 6bfbd2dc6db095ec05e53c894e048285f82446c6..ca53c01f60aef2040002f526b8f1b6a9094d1518 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);
+struct device *iris_create_cb_dev(struct iris_core *core, const char *name);
 
 #endif

-- 
2.34.1

[RFC PATCH 04/11] media: iris: Add helper to select relevant context bank device

[Vikash Garodia]

Associate the context bank device with the respective buffers. Fall back
to core->dev when the platform still describes the IOMMU on the parent
iris node instead of using subnodes. Those platforms would be migrated
gradually.

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    |  8 ++---
 drivers/media/platform/qcom/iris/iris_core.h      |  4 +++
 drivers/media/platform/qcom/iris/iris_hfi_queue.c | 16 +++++----
 drivers/media/platform/qcom/iris/iris_resources.c | 41 +++++++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_resources.h |  1 +
 drivers/media/platform/qcom/iris/iris_vidc.c      |  4 +--
 6 files changed, 61 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
index 246ad0abbac3510113e1f760406c81b1461377a3..249c9f1d0d5dadb391f269e9aee5181fe408cd3b 100644
--- a/drivers/media/platform/qcom/iris/iris_buffer.c
+++ b/drivers/media/platform/qcom/iris/iris_buffer.c
@@ -529,7 +529,7 @@ static int iris_create_internal_buffer(struct iris_inst *inst,
 				       enum iris_buffer_type buffer_type, u32 index)
 {
 	struct iris_buffers *buffers = &inst->buffers[buffer_type];
-	struct iris_core *core = inst->core;
+	struct device *dev = iris_get_cb_dev(inst, buffer_type);
 	struct iris_buffer *buffer;
 
 	if (!buffers->size)
@@ -545,7 +545,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);
@@ -682,10 +682,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(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_core.h b/drivers/media/platform/qcom/iris/iris_core.h
index 24da60448cf24820af7947b85eb7208555ab7786..3c96f46cf567b2802148b2a7cedb8488b6b9468b 100644
--- a/drivers/media/platform/qcom/iris/iris_core.h
+++ b/drivers/media/platform/qcom/iris/iris_core.h
@@ -36,6 +36,8 @@ struct qcom_ubwc_cfg_data;
  * struct iris_core - holds core parameters valid for all instances
  *
  * @dev: reference to device structure
+ * @np_dev: reference to non-pixel device structure
+ * @p_dev: reference to pixel device structure
  * @reg_base: IO memory base address
  * @irq: iris irq
  * @v4l2_dev: a holder for v4l2 device structure
@@ -81,6 +83,8 @@ struct qcom_ubwc_cfg_data;
 
 struct iris_core {
 	struct device				*dev;
+	struct device				*np_dev;
+	struct device				*p_dev;
 	void __iomem				*reg_base;
 	int					irq;
 	struct v4l2_device			v4l2_dev;
diff --git a/drivers/media/platform/qcom/iris/iris_hfi_queue.c b/drivers/media/platform/qcom/iris/iris_hfi_queue.c
index bf6db23b53e2106c08f2139b643f8626af8bc40a..ce6a682b0f9ada79f9fae26289db298855d777c2 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 = core->np_dev ? core->np_dev : core->dev;
 	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, queue_size, core->iface_q_table_vaddr,
+		dev_err(dev, "sfr alloc and map failed\n");
+		dma_free_attrs(dev, queue_size, 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 = core->np_dev ? core->np_dev : core->dev;
 	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 f550d194edf58abf0687a4f5df6d06b2af35147d..884715c8c841623f6803ac3d493c9a20520d5087 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.c
+++ b/drivers/media/platform/qcom/iris/iris_resources.c
@@ -12,6 +12,7 @@
 #include <linux/reset.h>
 
 #include "iris_core.h"
+#include "iris_instance.h"
 #include "iris_resources.h"
 
 #define BW_THRESHOLD 50000
@@ -164,3 +165,43 @@ struct device *iris_create_cb_dev(struct iris_core *core, const char *name)
 
 	return &pdev->dev;
 }
+
+struct device *iris_get_cb_dev(struct iris_inst *inst, enum iris_buffer_type buffer_type)
+{
+	struct iris_core *core = inst->core;
+	struct device *dev = NULL;
+
+	switch (buffer_type) {
+	case BUF_INPUT:
+		if (inst->domain == DECODER)
+			dev = core->np_dev;
+		else
+			dev = core->p_dev;
+		break;
+	case BUF_OUTPUT:
+		if (inst->domain == DECODER)
+			dev = core->p_dev;
+		else
+			dev = core->np_dev;
+		break;
+	case BUF_DPB:
+	case BUF_PARTIAL:
+	case BUF_SCRATCH_1:
+	case BUF_SCRATCH_2:
+	case BUF_VPSS:
+		dev = core->p_dev;
+		break;
+	case BUF_BIN:
+	case BUF_ARP:
+	case BUF_COMV:
+	case BUF_LINE:
+	case BUF_NON_COMV:
+	case BUF_PERSIST:
+		dev = core->np_dev;
+		break;
+	default:
+		dev_err(core->dev, "invalid buffer type: %d\n", buffer_type);
+	}
+
+	return dev ? dev : core->dev;
+}
diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
index ca53c01f60aef2040002f526b8f1b6a9094d1518..2eef0676a146f1836fc7445a715e43185c645099 100644
--- a/drivers/media/platform/qcom/iris/iris_resources.h
+++ b/drivers/media/platform/qcom/iris/iris_resources.h
@@ -16,5 +16,6 @@ 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);
 struct device *iris_create_cb_dev(struct iris_core *core, const char *name);
+struct device *iris_get_cb_dev(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 14d63dc76c9bacbed3533147cd5325410f9c94bd..26df872fb4fa1cc6b2aacebb7453256864b1462a 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, 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, BUF_OUTPUT);
 	dst_vq->lock = &inst->ctx_q_lock;
 
 	return vb2_queue_init(dst_vq);

-- 
2.34.1

[RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped

[Vikash Garodia]

The non-pixel and pixel subnodes move the IOMMU streams away from the
iris parent device. As a result, the core device may not have an IOMMU
mapping, and setting its DMA mask is unnecessary.
Legacy platforms that have not migrated to subnodes still associate the
streams with the parent device and still need the DMA mask setup. Call
dma_set_mask_and_coherent() only when an IOMMU is mapped to the iris
core device.

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_probe.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
index 0bce4fb1786bc9371074cb72e082219ded4840e5..828e020fc79a7f9c4e8e11c118996f61bcb7715d 100644
--- a/drivers/media/platform/qcom/iris/iris_probe.c
+++ b/drivers/media/platform/qcom/iris/iris_probe.c
@@ -309,9 +309,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(dev)) {
+		ret = dma_set_mask_and_coherent(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));

-- 
2.34.1

[RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[Vikash Garodia]

Iris platforms use separate context-bank devices for the pixel and
non-pixel domains. Add platform hooks to create and destroy those
subdevices, and wire them up for the affected platforms.

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/Makefile          |  1 +
 .../platform/qcom/iris/iris_platform_sm8550.c      | 71 ++++++++++++++++++++++
 .../platform/qcom/iris/iris_platform_sm8550.h      | 24 ++------
 .../media/platform/qcom/iris/iris_platform_vpu3x.c |  4 ++
 4 files changed, 80 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
--- a/drivers/media/platform/qcom/iris/Makefile
+++ b/drivers/media/platform/qcom/iris/Makefile
@@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
              iris_hfi_gen2_packet.o \
              iris_hfi_gen2_response.o \
              iris_hfi_queue.o \
+             iris_platform_sm8550.o \
              iris_platform_vpu2.o \
              iris_platform_vpu3x.o \
              iris_power.o \
diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
new file mode 100644
index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
--- /dev/null
+++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include "iris_core.h"
+#include "iris_platform_common.h"
+#include "iris_platform_sm8550.h"
+
+const char * const sm8550_clk_reset_table[] = { "bus" };
+
+const struct platform_clk_data sm8550_clk_table[] = {
+	{IRIS_AXI_CLK,  "iface"        },
+	{IRIS_CTRL_CLK, "core"         },
+	{IRIS_HW_CLK,   "vcodec0_core" },
+};
+
+struct platform_inst_caps platform_inst_cap_sm8550 = {
+	.min_frame_width = 96,
+	.max_frame_width = 8192,
+	.min_frame_height = 96,
+	.max_frame_height = 8192,
+	.max_mbpf = (8192 * 4352) / 256,
+	.mb_cycles_vpp = 200,
+	.mb_cycles_fw = 489583,
+	.mb_cycles_fw_vpp = 66234,
+	.max_frame_rate = MAXIMUM_FPS,
+	.max_operating_rate = MAXIMUM_FPS,
+};
+
+static int sm8550_init_cb_devs(struct iris_core *core)
+{
+	struct device *dev;
+
+	dev = iris_create_cb_dev(core, "non-pixel");
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
+
+	core->np_dev = dev;
+
+	dev = iris_create_cb_dev(core, "pixel");
+	if (IS_ERR(dev))
+		goto unreg_np_dev;
+
+	core->p_dev = dev;
+
+	return 0;
+
+unreg_np_dev:
+	if (core->np_dev)
+		platform_device_unregister(to_platform_device(core->np_dev));
+	core->np_dev = NULL;
+
+	return PTR_ERR(dev);
+}
+
+static void sm8550_deinit_cb_devs(struct iris_core *core)
+{
+	if (core->p_dev)
+		platform_device_unregister(to_platform_device(core->p_dev));
+	if (core->np_dev)
+		platform_device_unregister(to_platform_device(core->np_dev));
+
+	core->p_dev = NULL;
+	core->np_dev = NULL;
+}
+
+const struct iris_context_bank_ops sm8550_cb_ops = {
+	.init = sm8550_init_cb_devs,
+	.deinit = sm8550_deinit_cb_devs,
+};
diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.h b/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
index 3c9dae995bb248f66e200075021b3231b456300a..7205c9e27b1c56acd5a88a861df8eb75517d5a2b 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.h
@@ -6,25 +6,9 @@
 #ifndef __IRIS_PLATFORM_SM8550_H__
 #define __IRIS_PLATFORM_SM8550_H__
 
-static const char * const sm8550_clk_reset_table[] = { "bus" };
-
-static const struct platform_clk_data sm8550_clk_table[] = {
-	{IRIS_AXI_CLK,  "iface"        },
-	{IRIS_CTRL_CLK, "core"         },
-	{IRIS_HW_CLK,   "vcodec0_core" },
-};
-
-static struct platform_inst_caps platform_inst_cap_sm8550 = {
-	.min_frame_width = 96,
-	.max_frame_width = 8192,
-	.min_frame_height = 96,
-	.max_frame_height = 8192,
-	.max_mbpf = (8192 * 4352) / 256,
-	.mb_cycles_vpp = 200,
-	.mb_cycles_fw = 489583,
-	.mb_cycles_fw_vpp = 66234,
-	.max_frame_rate = MAXIMUM_FPS,
-	.max_operating_rate = MAXIMUM_FPS,
-};
+extern const char * const sm8550_clk_reset_table[1];
+extern const struct platform_clk_data sm8550_clk_table[3];
+extern struct platform_inst_caps platform_inst_cap_sm8550;
+extern const struct iris_context_bank_ops sm8550_cb_ops;
 
 #endif
diff --git a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
index 2c63adbc55791d5253b14096f9c3ce515f934a4e..68a021c3140eacbf72e63045d39f9b9b8d0e5d97 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
+++ b/drivers/media/platform/qcom/iris/iris_platform_vpu3x.c
@@ -91,6 +91,7 @@ static const struct tz_cp_config tz_cp_config_vpu3[] = {
  */
 const struct iris_platform_data qcs8300_data = {
 	.firmware_desc = &iris_vpu30_p4_s6_gen2_desc,
+	.cb_ops = &sm8550_cb_ops,
 	.vpu_ops = &iris_vpu3_ops,
 	.icc_tbl = iris_icc_info_vpu3x,
 	.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -120,6 +121,7 @@ const struct iris_platform_data qcs8300_data = {
 
 const struct iris_platform_data sm8550_data = {
 	.firmware_desc = &iris_vpu30_p4_gen2_desc,
+	.cb_ops = &sm8550_cb_ops,
 	.vpu_ops = &iris_vpu3_ops,
 	.icc_tbl = iris_icc_info_vpu3x,
 	.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -155,6 +157,7 @@ const struct iris_platform_data sm8550_data = {
  */
 const struct iris_platform_data sm8650_data = {
 	.firmware_desc = &iris_vpu33_p4_gen2_desc,
+	.cb_ops = &sm8550_cb_ops,
 	.vpu_ops = &iris_vpu33_ops,
 	.icc_tbl = iris_icc_info_vpu3x,
 	.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),
@@ -221,6 +224,7 @@ const struct iris_platform_data sm8750_data = {
  */
 const struct iris_platform_data x1p42100_data = {
 	.firmware_desc = &iris_vpu30_p1_gen2_desc,
+	.cb_ops = &sm8550_cb_ops,
 	.vpu_ops = &iris_vpu3_ops,
 	.icc_tbl = iris_icc_info_vpu3x,
 	.icc_tbl_size = ARRAY_SIZE(iris_icc_info_vpu3x),

-- 
2.34.1

[RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Vikash Garodia]

The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.

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>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
 			hwlocks = <&tcsr_mutex 3>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	qup_opp_table_100mhz: opp-table-qup100mhz {
@@ -5435,10 +5439,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";
 
-			iommus = <&apps_smmu 0x1940 0>,
-				 <&apps_smmu 0x1947 0>;
 			dma-coherent;
 
+			#address-cells = <2>;
+			#size-cells = <2>;
+
 			/*
 			 * IRIS firmware is signed by vendors, only
 			 * enable on boards where the proper signed firmware
@@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			 */
 			status = "disabled";
 
+			iris_non_pixel: non-pixel {
+				iommus = <&apps_smmu 0x1940 0x0>;
+				memory-region = <&iris_resv>;
+			};
+
+			iris_pixel: pixel {
+				iommus = <&apps_smmu 0x1947 0x0>;
+			};
+
 			iris_opp_table: opp-table {
 				compatible = "operating-points-v2";
 

-- 
2.34.1

[RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes

[Vikash Garodia]

The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.

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>
---
 arch/arm64/boot/dts/qcom/qcs8550.dtsi |  4 ++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi  | 18 ++++++++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
index f0acdd0b1e9384e684a90f7f49cf63633cd70d53..db0f539bc3d0a2e83b58b3929a05f0e44d9d513f 100644
--- a/arch/arm64/boot/dts/qcom/qcs8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
@@ -158,5 +158,9 @@ mpss_dsm_mem: mpss-dsm-region@d4d00000 {
 			reg = <0x0 0xd4d00000 0x0 0x3300000>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 83136efb7724c3d74f9f377b1c8291d7378ac4a8..347d4a03b1ba419a2856a7c8ae98d6b26e90ad6b 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1087,6 +1087,10 @@ hyp_ext_reserved_mem: hyp-ext-reserved-region@ff700000 {
 			reg = <0 0xff700000 0 0x100000>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -3690,10 +3694,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";
 
-			iommus = <&apps_smmu 0x1940 0>,
-				 <&apps_smmu 0x1947 0>;
 			dma-coherent;
 
+			#address-cells = <2>;
+			#size-cells = <2>;
+
 			/*
 			 * IRIS firmware is signed by vendors, only
 			 * enable on boards where the proper signed firmware
@@ -3701,6 +3706,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			 */
 			status = "disabled";
 
+			iris_non_pixel: non-pixel {
+				iommus = <&apps_smmu 0x1940 0x0>;
+				memory-region = <&iris_resv>;
+			};
+
+			iris_pixel: pixel {
+				iommus = <&apps_smmu 0x1947 0x0>;
+			};
+
 			iris_opp_table: opp-table {
 				compatible = "operating-points-v2";
 

-- 
2.34.1

[RFC PATCH 09/11] arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes

[Vikash Garodia]

The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.

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>
---
 arch/arm64/boot/dts/qcom/lemans.dtsi | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index a10322c5bc35754042640d56ecb556a5ed5cf281..90c300461b5029b4084b8b28130cd826155e4cbb 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -879,6 +879,10 @@ cpucp_fw_mem: cpucp-fw@db200000 {
 			reg = <0x0 0xdb200000 0x0 0x100000>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -4978,12 +4982,22 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";
 
-			iommus = <&apps_smmu 0x0880 0x0400>,
-				 <&apps_smmu 0x0887 0x0400>;
 			dma-coherent;
 
+			#address-cells = <2>;
+			#size-cells = <2>;
+
 			status = "disabled";
 
+			iris_non_pixel: non-pixel {
+				iommus = <&apps_smmu 0x0880 0x0400>;
+				memory-region = <&iris_resv>;
+			};
+
+			iris_pixel: pixel {
+				iommus = <&apps_smmu 0x0887 0x0400>;
+			};
+
 			iris_opp_table: opp-table {
 				compatible = "operating-points-v2";
 

-- 
2.34.1

[RFC PATCH 10/11] arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes

[Vikash Garodia]

The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.

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>
---
 arch/arm64/boot/dts/qcom/monaco.dtsi | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index e0243901abe9c5748fcd3c448a0203374fb96c3e..d3c464571d5eee18fccb0e6b522ff0400e664cc4 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -831,6 +831,10 @@ video_mem: video-region@9be82000 {
 			reg = <0x0 0x9be82000 0x0 0x700000>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -5423,12 +5427,22 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";
 
-			iommus = <&apps_smmu 0x0880 0x0400>,
-				 <&apps_smmu 0x0887 0x0400>;
 			dma-coherent;
 
+			#address-cells = <2>;
+			#size-cells = <2>;
+
 			status = "disabled";
 
+			iris_non_pixel: non-pixel {
+				iommus = <&apps_smmu 0x0880 0x0400>;
+				memory-region = <&iris_resv>;
+			};
+
+			iris_pixel: pixel {
+				iommus = <&apps_smmu 0x0887 0x0400>;
+			};
+
 			iris_opp_table: opp-table {
 				compatible = "operating-points-v2";
 

-- 
2.34.1

[RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

[Vikash Garodia]

The Iris VPU has separate streams with different IOVA constraints. The
non-pixel stream must be limited to the 0-600 MB IOVA range, while the
pixel stream can use the full IOVA space.
Using a single set of IOMMU entries for the Iris node does not describe
these per-stream limits and can allow accesses outside the supported
range, which may lead to device crashes. One such issue was reported at:
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Add non-pixel and pixel child nodes, move each stream ID to its
corresponding child node, and add a reserved IOVA range for the
non-pixel stream.

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>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 447b788fcbb96efc8b26a52a0606bc53dd29adfb..f9c03de1317f1c6a8e52bd897997ef7bd826926b 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -1849,6 +1849,10 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
 			reg = <0 0xff800000 0 0x600000>;
 			no-map;
 		};
+
+		iris_resv: reservation-iris {
+			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -5219,11 +5223,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 				      "xo",
 				      "core";
 
-			iommus = <&apps_smmu 0x1940 0>,
-				 <&apps_smmu 0x1947 0>;
-
 			dma-coherent;
 
+			#address-cells = <2>;
+			#size-cells = <2>;
+
 			/*
 			 * IRIS firmware is signed by vendors, only
 			 * enable on boards where the proper signed firmware
@@ -5231,6 +5235,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			 */
 			status = "disabled";
 
+			iris_non_pixel: non-pixel {
+				iommus = <&apps_smmu 0x1940 0x0>;
+				memory-region = <&iris_resv>;
+			};
+
+			iris_pixel: pixel {
+				iommus = <&apps_smmu 0x1947 0x0>;
+			};
+
 			iris_opp_table: opp-table {
 				compatible = "operating-points-v2";
 

-- 
2.34.1

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `oneOf` constraint allows invalid hybrid configurations with both top-level `iommus` and a single stream subnode.
- [Low] Unnecessary `#address-cells` and `#size-cells` properties added to the parent node will trigger a `dtc` warning because no child nodes have `reg` or `ranges` properties.
--

--- Patch [1]: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes ---
commit 952135a9f5f9889eefcc3ad627cf18f885374f2d
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

VPU hardwares have a limitation where VPU streams are associated with
dedicated addressable address range. To address this limitation, the subset
of stream/s are now represented as sub nodes, so that they can be associated
to the respective addressable range.

> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 0400ca1bff05d..bf4d24ce90bd3 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -91,6 +91,51 @@ properties:
>    opp-table:
>      type: object
>  
> +  '#address-cells':
> +    const: 2
> +
> +  '#size-cells':
> +    const: 2
> +

[Severity: Low]
Does the addition of #address-cells and #size-cells properties to the parent
node trigger a dtc warning?

Since none of the new child nodes (non-pixel, pixel, firmware, or opp-table)
use a reg or ranges property, the avoid_unnecessary_addr_size compiler warning
might be triggered during dt_binding_check.

[ ... ]

> @@ -98,9 +143,15 @@ required:
>    - interconnect-names
>    - resets
>    - reset-names
> -  - iommus
>    - dma-coherent
>  
> +oneOf:
> +  - required:
> +      - iommus
> +  - required:
> +      - non-pixel
> +      - pixel
> +

[Severity: Medium]
Will this oneOf constraint allow invalid hybrid configurations to pass
validation?

If a devicetree incorrectly specifies a top-level iommus property alongside
only one of the subnodes (such as non-pixel), the first branch evaluates to
true and the second branch evaluates to false. Because exactly one branch is
true, the oneOf condition is satisfied instead of rejecting the hybrid state.

Should the branches explicitly forbid the properties of the other branch to
prevent this?

[ ... ]

> @@ -177,12 +228,21 @@ examples:
>          resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>          reset-names = "bus";
>  
> -        iommus = <&apps_smmu 0x1940 0x0000>,
> -                 <&apps_smmu 0x1947 0x0000>;
>          dma-coherent;
>  
>          operating-points-v2 = <&iris_opp_table>;
>  
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        iris_non_pixel: non-pixel {

[Severity: Low]
Does explicitly setting these properties in the example cause dt_binding_check
to emit a warning due to the lack of reg properties in the child nodes?

> +            iommus = <&apps_smmu 0x1940 0x0000>;
> +            memory-region = <&iris_resv>;
> +        };
> +
> +        iris_pixel: pixel {
> +            iommus = <&apps_smmu 0x1947 0x0000>;
> +        };
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=1

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Dmitry Baryshkov]

On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
> VPU hardwares have a limitation where VPU streams are associated with
> dedicated addressable address range, as illustrated below
> 
>     +-----------------------------------------------------------+
>     | Stream A reserved region (600 MB)                         |
>     | 0x00000000 - 0x25800000                                   |
>     +-----------------------------------------------------------+
>     | Stream B reserved region (3.5 GB)                         |
>     | 0x00000000 - 0xe0000000                                   |
>     +-----------------------------------------------------------+
>     | Other reserved regions                                    |
>     +-----------------------------------------------------------+
> 
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> To address this limitation, the subset of stream/s are now represented as
> sub nodes, so that they can be associated to the respective addressable
> range.
> The limitation could be exposed when running usecase like concurrent
> video sessions. The binding have been validated with higher concurrent
> sessions across the SOCs supported under this schema.
> 
> 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>
> ---
>  .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
>  1 file changed, 63 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -91,6 +91,51 @@ properties:
>    opp-table:
>      type: object
>  
> +  '#address-cells':
> +    const: 2
> +
> +  '#size-cells':
> +    const: 2
> +
> +  non-pixel:
> +    type: object
> +    description:
> +      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> +      buffers. Non pixel buffers are compressed and internal buffers.
> +    properties:
> +      iommus:
> +        maxItems: 1
> +      memory-region:
> +        maxItems: 1
> +    required:
> +      - iommus
> +      - memory-region
> +    additionalProperties: false
> +
> +  pixel:
> +    type: object
> +    description:
> +      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> +      Pixel buffers are uncompressed buffers.
> +    properties:
> +      iommus:
> +        maxItems: 1
> +    required:
> +      - iommus
> +    additionalProperties: false
> +
> +  firmware:
> +    type: object
> +    description:
> +      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> +      VPU when no hypervisor is present.
> +    properties:
> +      iommus:
> +        maxItems: 1
> +    required:
> +      - iommus
> +    additionalProperties: false
> +
>  required:
>    - compatible
>    - power-domain-names
> @@ -98,9 +143,15 @@ required:
>    - interconnect-names
>    - resets
>    - reset-names
> -  - iommus
>    - dma-coherent
>  
> +oneOf:
> +  - required:
> +      - iommus
> +  - required:
> +      - non-pixel
> +      - pixel
> +
>  allOf:
>    - if:
>        properties:
> @@ -177,12 +228,21 @@ examples:
>          resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>          reset-names = "bus";
>  
> -        iommus = <&apps_smmu 0x1940 0x0000>,
> -                 <&apps_smmu 0x1947 0x0000>;
>          dma-coherent;
>  
>          operating-points-v2 = <&iris_opp_table>;
>  
> +        #address-cells = <2>;
> +        #size-cells = <2>;

I think you need "ranges;" here. Also an empty line before the subnodes.

> +        iris_non_pixel: non-pixel {

Drop useless labels.

> +            iommus = <&apps_smmu 0x1940 0x0000>;
> +            memory-region = <&iris_resv>;
> +        };
> +
> +        iris_pixel: pixel {
> +            iommus = <&apps_smmu 0x1947 0x0000>;
> +        };
> +
>          iris_opp_table: opp-table {
>              compatible = "operating-points-v2";
>  
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] The `iris_core` structure is allocated with `devm_kzalloc` but referenced by video devices that can outlive the device unbind process.
- [High] Missing cancellation of the `sys_error_handler` delayed work in `iris_remove`.
- [High] Hardware and queues are deinitialized before userspace access is revoked in `iris_remove`.
--

--- Patch [2]: [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks ---
commit 746928806b2d799681dddbd3d539730ff7f9d31a
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Add hooks to initialize and tear down context banks

This commit adds platform hooks to set up and tear down context bank
devices. It updates the platform data structure to include these hooks
and modifies the probe and remove functions to call them.

> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> index c2dcb50a27824..0bce4fb1786bc 100644
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
[ ... ]
> @@ -207,6 +221,8 @@ static void iris_remove(struct platform_device *pdev)
>  
>  	v4l2_device_unregister(&core->v4l2_dev);
>  
> +	iris_deinit_cb_devs(core);
> +

[Severity: High]
This is a pre-existing issue, but are the hardware and queues deinitialized
before userspace access is revoked?

iris_core_deinit(core) is called before video_unregister_device() (higher up
in this function). Because the video device is still registered, userspace
can concurrently call open().

iris_open() calls iris_core_init(), which sees IRIS_CORE_DEINIT and
re-allocates the DMA queues and powers on the hardware. When iris_remove()
completes, devres frees core, but the newly allocated DMA memory is leaked.

Furthermore, the successfully opened file descriptor will now operate on a
freed core structure, leading to a use-after-free.

[Severity: High]
This is a pre-existing issue, but should the sys_error_handler delayed work
be canceled here?

The delayed work sys_error_handler is scheduled by the HFI interrupt handler
when a system error occurs. Because the interrupt is devm-managed, it
remains active throughout iris_remove().

If the interrupt fires and schedules the work during unbind, the work will
execute asynchronously after iris_remove() completes and devres frees core.
The work handler iris_sys_error_handler() will then dereference the freed
core structure.

>  	mutex_destroy(&core->lock);
>  }
>  
> @@ -273,10 +289,14 @@ static int iris_probe(struct platform_device *pdev)
>  
>  	iris_session_init_caps(core);
>  
> -	ret = v4l2_device_register(dev, &core->v4l2_dev);
> +	ret = iris_init_cb_devs(core);
>  	if (ret)
>  		return ret;
>  
> +	ret = v4l2_device_register(dev, &core->v4l2_dev);
> +	if (ret)
> +		goto err_cb_deinit;
> +
>  	ret = iris_register_video_device(core, DECODER);

[Severity: High]
This is a pre-existing issue, but can the core structure outlive its
allocation?

The core structure is allocated with devm_kzalloc() earlier in probe, which
ties its lifetime to the device unbind process. However,
video_unregister_device() does not force-close active file descriptors.

If a user-space application holds the video node open while the driver is
unbound, devres will free the core structure. When the user application later
calls close(), V4L2 invokes iris_close():

drivers/media/platform/qcom/iris/iris_vidc.c:iris_close() {
    struct iris_inst *inst = iris_get_inst(filp);
    ...
    iris_remove_session(inst);
}

This path attempts to acquire core->lock on the already freed core object.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=2

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Dmitry Baryshkov]

On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.
> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
> 
> 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>
> ---
>  arch/arm64/boot/dts/qcom/hamoa.dtsi | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
>  			hwlocks = <&tcsr_mutex 3>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};
>  	};
>  
>  	qup_opp_table_100mhz: opp-table-qup100mhz {
> @@ -5435,10 +5439,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>  			reset-names = "bus";
>  
> -			iommus = <&apps_smmu 0x1940 0>,
> -				 <&apps_smmu 0x1947 0>;
>  			dma-coherent;
>  
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +
>  			/*
>  			 * IRIS firmware is signed by vendors, only
>  			 * enable on boards where the proper signed firmware
> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			 */
>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				memory-region = <&iris_resv>;
> +			};
> +
> +			iris_pixel: pixel {

Unused label. Also, shouldn't you specify the IOMMU region for this one
too?

> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};
> +
>  			iris_opp_table: opp-table {
>  				compatible = "operating-points-v2";
>  
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [RFC PATCH 03/11] media: iris: Add helper to create a context bank device

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The context bank platform device is registered with a hardcoded instance ID of 0 instead of `PLATFORM_DEVID_AUTO`, causing sysfs naming collisions and probe failures when multiple instances of the Iris core are present.
--

--- Patch [3]: [RFC PATCH 03/11] media: iris: Add helper to create a context bank device ---
commit d34d83e19b25d09de0876c75096c26d30aa90223
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Add helper to create a context bank device

This commit adds a helper function to register a subnode from the device
tree as a separate platform device, allowing it to have its own IOMMU
context bank.

> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
> --- a/drivers/media/platform/qcom/iris/iris_resources.c
> +++ b/drivers/media/platform/qcom/iris/iris_resources.c

[ ... ]

> +struct device *iris_create_cb_dev(struct iris_core *core, const char *name)
> +{
> +	struct platform_device_info plat_dev_info = {};
> +	struct device_node *child_of_node;
> +	struct platform_device *pdev;
> +
> +	child_of_node = of_get_child_by_name(core->dev->of_node, name);
> +	if (!child_of_node)
> +		return NULL;
> +
> +	plat_dev_info.dma_mask = core->iris_platform_data->dma_mask;
> +	plat_dev_info.fwnode = &child_of_node->fwnode;
> +	plat_dev_info.name = child_of_node->name;
> +	plat_dev_info.parent = core->dev;
> +
> +	pdev = platform_device_register_full(&plat_dev_info);

[Severity: Medium]
Does this code risk a sysfs naming collision if multiple Iris instances are
present?

Since plat_dev_info is zero-initialized, the device id defaults to 0 instead
of PLATFORM_DEVID_AUTO. If the SoC device tree specifies multiple Iris cores,
won't the second instance fail to register its context bank device due to a
sysfs naming collision in /sys/bus/platform/devices/ (for example, trying
to register a device named 'pixel.0' twice)?

> +	of_node_put(child_of_node);
> +	if (IS_ERR(pdev))
> +		return ERR_CAST(pdev);
> +
> +	return &pdev->dev;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=3

Re: [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped

[Dmitry Baryshkov]

On Thu, Jul 09, 2026 at 06:05:51PM +0530, Vikash Garodia wrote:
> The non-pixel and pixel subnodes move the IOMMU streams away from the
> iris parent device. As a result, the core device may not have an IOMMU
> mapping, and setting its DMA mask is unnecessary.
> Legacy platforms that have not migrated to subnodes still associate the
> streams with the parent device and still need the DMA mask setup. Call
> dma_set_mask_and_coherent() only when an IOMMU is mapped to the iris
> core device.
> 
> 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_probe.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[Dmitry Baryshkov]

On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
> Iris platforms use separate context-bank devices for the pixel and
> non-pixel domains. Add platform hooks to create and destroy those
> subdevices, and wire them up for the affected platforms.
> 
> 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/Makefile          |  1 +
>  .../platform/qcom/iris/iris_platform_sm8550.c      | 71 ++++++++++++++++++++++
>  .../platform/qcom/iris/iris_platform_sm8550.h      | 24 ++------
>  .../media/platform/qcom/iris/iris_platform_vpu3x.c |  4 ++
>  4 files changed, 80 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
> --- a/drivers/media/platform/qcom/iris/Makefile
> +++ b/drivers/media/platform/qcom/iris/Makefile
> @@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
>               iris_hfi_gen2_packet.o \
>               iris_hfi_gen2_response.o \
>               iris_hfi_queue.o \
> +             iris_platform_sm8550.o \

No, it's not a separate platform.

>               iris_platform_vpu2.o \
>               iris_platform_vpu3x.o \
>               iris_power.o \
> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "iris_core.h"
> +#include "iris_platform_common.h"
> +#include "iris_platform_sm8550.h"
> +
> +const char * const sm8550_clk_reset_table[] = { "bus" };
> +
> +const struct platform_clk_data sm8550_clk_table[] = {
> +	{IRIS_AXI_CLK,  "iface"        },
> +	{IRIS_CTRL_CLK, "core"         },
> +	{IRIS_HW_CLK,   "vcodec0_core" },
> +};
> +
> +struct platform_inst_caps platform_inst_cap_sm8550 = {
> +	.min_frame_width = 96,
> +	.max_frame_width = 8192,
> +	.min_frame_height = 96,
> +	.max_frame_height = 8192,
> +	.max_mbpf = (8192 * 4352) / 256,
> +	.mb_cycles_vpp = 200,
> +	.mb_cycles_fw = 489583,
> +	.mb_cycles_fw_vpp = 66234,
> +	.max_frame_rate = MAXIMUM_FPS,
> +	.max_operating_rate = MAXIMUM_FPS,
> +};
> +
> +static int sm8550_init_cb_devs(struct iris_core *core)
> +{
> +	struct device *dev;
> +
> +	dev = iris_create_cb_dev(core, "non-pixel");
> +	if (IS_ERR(dev))
> +		return PTR_ERR(dev);
> +
> +	core->np_dev = dev;
> +
> +	dev = iris_create_cb_dev(core, "pixel");
> +	if (IS_ERR(dev))
> +		goto unreg_np_dev;
> +
> +	core->p_dev = dev;
> +
> +	return 0;
> +
> +unreg_np_dev:
> +	if (core->np_dev)
> +		platform_device_unregister(to_platform_device(core->np_dev));
> +	core->np_dev = NULL;
> +
> +	return PTR_ERR(dev);
> +}
> +
> +static void sm8550_deinit_cb_devs(struct iris_core *core)
> +{
> +	if (core->p_dev)
> +		platform_device_unregister(to_platform_device(core->p_dev));
> +	if (core->np_dev)
> +		platform_device_unregister(to_platform_device(core->np_dev));
> +
> +	core->p_dev = NULL;
> +	core->np_dev = NULL;
> +}
> +
> +const struct iris_context_bank_ops sm8550_cb_ops = {

For a long time I have been asking to fix name prefixes. Now you are
adding one more. No. Please write it as a rule of thumb. All new symbols
in the iris driver should start with iris_.

Moreover, there is nothing sm8550-specific in these hooks. Enable them
for all VPU3.x platforms uniformly.

> +	.init = sm8550_init_cb_devs,
> +	.deinit = sm8550_deinit_cb_devs,
> +};

-- 
With best wishes
Dmitry

Re: [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing DMA segment size configuration for newly introduced subnodes.
--

--- Patch [5]: [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped ---
commit 767f9e3fe023f5e91b49d0a9ac0e6e7678556f9b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Skip DMA mask setting to core device when IOMMU is not mapped

This commit conditionally skips setting the DMA mask on the core device
if it does not have an IOMMU mapping. This addresses platforms where
subnodes are used for IOMMU streams instead of the parent device.

> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> index 0bce4fb1786bc..828e020fc79a7 100644
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> @@ -309,9 +309,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(dev)) {
> +		ret = dma_set_mask_and_coherent(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));

[Severity: Low]
Since the DMA mask is conditionally skipped for the parent device when
subnodes are in use, do we also need to set these max segment size and
boundary limits on the subnode devices that are actually performing the
DMA?

If an application imports a large dma-buf for video streaming, the subnode
devices appear to inherit the default 64KB maximum segment size limit. When
vb2_dma_contig() calls dma_map_sgtable() using the subnode device, the IOMMU
driver might attempt to process segments larger than the unconfigured 64KB
default.

Could this trigger a DMA API debug warning ("mapping sg segment longer
than device claims to support") and introduce unnecessary CPU overhead
as the IOMMU driver evaluates splitting the mapping?

Would it make sense to configure these DMA parameters for the subnodes
in iris_create_cb_dev() as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=5

Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Unregistering context bank devices in `remove` while V4L2 FDs are open causes DMA API mismatch and IOMMU faults.
- [Medium] Hardcoded platform device ID causes name collision if multiple Iris instances exist.

Pre-existing issues:
- [High] Missing cancellation of sys_error_handler delayed work leads to Use-After-Free.
- [High] Use-After-Free on `iris_core` during deferred V4L2 close due to `devm_kzalloc`.
--

--- Patch [6]: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks ---
commit ac38538cd2eb8a1aa776f7262b1bd953d7ac3a78
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Add hooks for pixel and non-pixel context banks
    
Iris platforms use separate context-bank devices for the pixel and
non-pixel domains. Add platform hooks to create and destroy those
subdevices, and wire them up for the affected platforms.

> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> new file mode 100644
> index 0000000000000..bea904a9249ba
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
> @@ -0,0 +1,71 @@

[ ... ]

> +static int sm8550_init_cb_devs(struct iris_core *core)
> +{
> +	struct device *dev;
> +
> +	dev = iris_create_cb_dev(core, "non-pixel");

[Severity: Medium]
When creating the child context banks here, could this cause a name
collision if there are multiple Iris instances?

Looking at iris_create_cb_dev() in iris_resources.c, it zero-initializes
struct platform_device_info, which forces the device id to 0:

drivers/media/platform/qcom/iris/iris_resources.c:iris_create_cb_dev() {
	struct platform_device_info plat_dev_info = {};
	...
}

This causes platform_device_register_full() to assign exact names like
"pixel.0" and "non-pixel.0". If a second Iris instance probes, wouldn't
kobject_add() return -EEXIST? Should PLATFORM_DEVID_AUTO be used instead?

> +	if (IS_ERR(dev))
> +		return PTR_ERR(dev);
> +
> +	core->np_dev = dev;
> +
> +	dev = iris_create_cb_dev(core, "pixel");

[ ... ]

> +static void sm8550_deinit_cb_devs(struct iris_core *core)
> +{
> +	if (core->p_dev)
> +		platform_device_unregister(to_platform_device(core->p_dev));
> +	if (core->np_dev)
> +		platform_device_unregister(to_platform_device(core->np_dev));
> +
> +	core->p_dev = NULL;
> +	core->np_dev = NULL;
> +}

[Severity: High]
Does unregistering the context bank devices here cause a DMA API mismatch if
a user-space application still holds a V4L2 file descriptor open?

V4L2 file handles can outlive the driver's remove callback. If a user closes
the device after remove completes, iris_close() calls
iris_destroy_all_internal_buffers() which calls iris_get_cb_dev().

Since p_dev and np_dev are NULL, iris_get_cb_dev() falls back to core->dev:

drivers/media/platform/qcom/iris/iris_resources.c:iris_get_cb_dev() {
	...
	return dev ? dev : core->dev;
}

This means dma_free_attrs() is executed using core->dev, but the memory
was originally allocated with the context bank devices. Could this mismatch
violate the DMA API and cause IOMMU unmap faults?

[Severity: High]
This is a pre-existing issue, but does tying the iris_core struct to the
device lifecycle result in a Use-After-Free during a deferred V4L2 close?

In iris_probe(), core is allocated with devm_kzalloc():

drivers/media/platform/qcom/iris/iris_probe.c:iris_probe() {
	...
	core = devm_kzalloc(&pdev->dev, sizeof(*core), GFP_KERNEL);
	...
}

When the driver is unbound, iris_remove() returns and devres frees core.
If an application holds a file descriptor open, iris_close() is eventually
called, which dereferences inst->core to clean up sessions:

drivers/media/platform/qcom/iris/iris_vidc.c:iris_close() {
	...
	iris_remove_session(inst);
	...
}

Since core is already freed, won't this cause memory corruption?

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for the
sys_error_handler delayed work to trigger a Use-After-Free if it runs
during or after driver unbind?

The sys_error_handler is dynamically scheduled on hardware errors, but
iris_remove() does not appear to cancel it:

drivers/media/platform/qcom/iris/iris_probe.c:iris_remove() {
	struct iris_core *core;

	core = platform_get_drvdata(pdev);
	if (!core)
		return;

	iris_core_deinit(core);
}

If the unbind occurs while the work is pending or running, core will be
freed by devres after iris_remove() returns. When the workqueue executes
iris_sys_error_handler(), won't it dereference the freed core?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=6

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `iommu-addresses` property is incorrectly used to limit the non-pixel stream's IOVA space. Instead of restricting allocations to the 0-600 MB range, it marks the range as an IOMMU reservation (`IOMMU_RESV_RESERVED`), which forces the allocator to skip it and allocate IOVAs above 600 MB, directly violating hardware constraints.
--

--- Patch [7]: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes ---
commit 96b940efc5fae7db37d762be78144fc901472a7b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

This commit splits the Iris VPU into non-pixel and pixel sub-nodes to
describe separate IOVA constraints. It uses a reserved memory region with
iommu-addresses to attempt limiting the non-pixel stream to the 0-600 MB
range.

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
>  			hwlocks = <&tcsr_mutex 3>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};

[Severity: High]
Does this iommu-addresses property actually restrict allocations to the
0-600 MB range, or does it do the exact opposite?

Because this reservation node lacks a physical reg property,
of_iommu_get_resv_regions() parses it as an IOMMU_RESV_RESERVED region.
When iova_reserve_iommu_regions() processes this, it permanently blocks
the 0-600 MB range from the device's IOVA allocator.

Could this force the allocator to fall back to IOVAs above 600 MB (or
fail entirely), directly violating the hardware constraint and leading to
the device crashes mentioned in the commit message?

>  	};
>  
[ ... ]
> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			 */
>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				memory-region = <&iris_resv>;
> +			};
> +
> +			iris_pixel: pixel {
> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=7

Re: [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The `reservation-iris` node uses `iommu-addresses` without a `reg` property. In `of_iommu_get_resv_regions`, this is parsed as an `IOMMU_RESV_RESERVED` region. The IOMMU subsystem explicitly reserves these regions in the IOVA allocator tree (e.g., in `reserve_iova`), which prevents any DMA allocations from using this memory range. Instead of limiting the non-pixel stream to the 0-600 MB IOVA range, this patch effectively denylists the 0-600 MB range, forcing all allocations to use IOVAs above 600 MB. This inverts the intended hardware constraint and will cause the VPU crashes it aims to prevent.
- [High] The `non-pixel` and `pixel` child nodes lack `compatible` strings and do not bind to any platform driver. The driver registers them using `platform_device_register_full()`, but because no driver probes them, the driver core never calls `platform_dma_configure()` (and thus `of_dma_configure()`) for these devices. Consequently, their `dev->iommu_fwspec` and DMA ops remain unconfigured. When `dma_alloc_attrs()` is later called using these context bank devices, the allocations will bypass the IOMMU (falling back to direct physical memory allocations) and trigger SMMU translation faults. The driver must manually invoke `of_dma_configure()` on the created child devices.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but in `of_iommu_get_resv_regions`, if `of_translate_dma_region()` fails (e.g., crossing a non-translatable boundary or encountering a malformed `dma-ranges`), it returns `NULL`, which is assigned to the `maps` pointer. Because `length` is uninitialized, it can be non-zero, allowing the code to bypass the `if (length == 0)` check. The loop condition `while (maps < end)` evaluates to true (since `NULL < end`), and the next iteration immediately dereferences the `NULL` pointer at `be32_to_cpup(maps++)`, resulting in a kernel panic.
- [High] This problem wasn't introduced by this patch, but `of_iommu_get_resv_regions` lacks bounds checking when parsing `iommu-addresses`. The loop blindly advances `maps` cell by cell, without skipping the address and size data for unmatched phandles. If a data cell coincidentally matches `dev->of_node`'s phandle, or if the property is truncated, `of_translate_dma_region` delegates to `__of_translate_address`, which executes `memcpy(addr, in_addr, na * 4)` and `of_read_number(prop + na, ns)` without ensuring there are `na + ns` cells remaining before `end`. This leads to an out-of-bounds read of the device tree property.
--

--- Patch [8]: [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes ---
commit 84b6e774da5044311b95ef6d8c3458ace387439e
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Subject: arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes

This commit separates the Iris VPU IOMMUs into pixel and non-pixel child
nodes to describe their different IOVA constraints. It also attempts to
restrict the non-pixel stream to the 0-600 MB IOVA range using a memory
reservation node.

> diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> --- a/arch/arm64/boot/dts/qcom/qcs8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi

[ ... ]

> @@ -158,5 +158,9 @@ mpss_dsm_mem: mpss-dsm-region@d4d00000 {
>  			reg = <0x0 0xd4d00000 0x0 0x3300000>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};
>  	};
>  };

[Severity: High]
Does this configuration actually reserve the 0-600 MB range for the non-pixel
stream to use, or does it unintentionally prevent its use?

Since the reservation-iris node uses iommu-addresses without a reg property,
the IOMMU subsystem parses this as an IOMMU_RESV_RESERVED region. The IOVA
allocator explicitly denylists reserved regions to protect them, preventing
any DMA allocations from using that memory range.

Will this force all non-pixel stream allocations into higher addresses
outside the 0-600 MB range, potentially causing the VPU crashes this aims
to prevent?

[Severity: High]
This isn't a bug introduced by this patch, but does the addition of the
iommu-addresses property expose an unhandled failure path in the IOMMU core?

If address translation fails for any reason (like a malformed property),
of_translate_dma_region() returns a NULL pointer. Because the length variable
is uninitialized, the code can bypass the length == 0 check:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
	...
	maps = of_translate_dma_region(np, maps, &iova, &length);
	if (length == 0)
		continue;
	
	phandle = be32_to_cpup(maps++);
	...
}

The loop condition while (maps < end) remains true, and the next iteration
will immediately dereference the NULL pointer at be32_to_cpup(maps++),
causing a kernel panic. 

[Severity: High]
This is also a pre-existing issue, but does parsing the iommu-addresses
property risk an out-of-bounds read?

The loop in of_iommu_get_resv_regions() advances the maps pointer cell by
cell. If a data cell coincidentally matches a device phandle, it calls
of_translate_dma_region() which blindly delegates the copy:

drivers/of/address.c:__of_translate_address() {
	...
	memcpy(addr, in_addr, na * 4);
	...
}

If there are not enough cells remaining before the end of the property
array, could this read past the allocated bounds of the device tree
property?

> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi

[ ... ]

> @@ -3690,10 +3694,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>  			reset-names = "bus";
>  
> -			iommus = <&apps_smmu 0x1940 0>,
> -				 <&apps_smmu 0x1947 0>;
>  			dma-coherent;
>  
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +
>  			/*
>  			 * IRIS firmware is signed by vendors, only
>  			 * enable on boards where the proper signed firmware
> @@ -3701,6 +3706,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			 */
>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				memory-region = <&iris_resv>;
> +			};
> +
> +			iris_pixel: pixel {
> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};
> +
>  			iris_opp_table: opp-table {
>  				compatible = "operating-points-v2";

[Severity: High]
Because these child nodes lack compatible strings, they do not bind to any
platform driver. When the driver registers them, is their DMA configuration
left uninitialized?

The driver core calls platform_dma_configure() automatically when a driver
probes. Without a driver binding, the device's iommu_fwspec and DMA ops
remain unconfigured:

drivers/media/platform/qcom/iris/iris_resources.c:iris_create_cb_dev() {
	...
	pdev = platform_device_register_full(&plat_dev_info);
	/* of_dma_configure() is not called manually here */
}

When the driver later calls dma_alloc_attrs() for these context bank
devices, will it bypass the IOMMU entirely and trigger SMMU translation
faults?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=8

Re: [RFC PATCH 09/11] arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `iommu-addresses` in a `reserved-memory` node explicitly blacklists the 0-600 MB IOVA range instead of limiting the device to it.
--

--- Patch [9]: [RFC PATCH 09/11] arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes ---
commit b935406806a9ce7b7ad2277e27ed775abba4a09e
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: lemans: Move Iris IOMMUs to child nodes

This commit splits the Iris VPU into non-pixel and pixel child nodes with
their respective IOMMUs. It attempts to restrict the non-pixel stream to
the 0-600 MB IOVA range by adding a reserved IOVA range.

> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> --- a/arch/arm64/boot/dts/qcom/lemans.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
> @@ -879,6 +879,10 @@ cpucp_fw_mem: cpucp-fw@db200000 {
>  			reg = <0x0 0xdb200000 0x0 0x100000>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};
>  	};
>  
>  	smp2p-adsp {

[ ... ]

>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x0880 0x0400>;
> +				memory-region = <&iris_resv>;
> +			};

[Severity: High]
Will this inadvertently exclude the 0-600 MB IOVA range from the available
allocator space instead of restricting the device to it?

During domain initialization, the IOMMU subsystem parses iommu-addresses
without a reg property as an IOMMU_RESV_RESERVED region.

It then calls reserve_iova() to remove this exact range from the IOVA
allocator's available space. Because the non-pixel device is linked to this
memory-region, all subsequent DMA allocations for the non-pixel stream will
avoid the 0-600 MB range entirely.

This forces the device to use DMA allocations strictly > 600 MB, which
seems to guarantee the exact out-of-range memory accesses and device crashes
the patch intends to fix.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=9

Re: [RFC PATCH 10/11] arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Misuse of `iommu-addresses` in a `reserved-memory` node creates an `IOMMU_RESV_RESERVED` region that actively blocks IOVA allocations in the 0-600MB range, rather than restricting allocations to it.
--

--- Patch [10]: [RFC PATCH 10/11] arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes ---
commit 2ee0f65b225528a8b439c85350380c9a56ad101f
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: monaco: Move Iris IOMMUs to child nodes

This commit splits the Iris VPU device into non-pixel and pixel child nodes
to accommodate different IOVA constraints. It adds a reserved IOVA range
intending to limit the non-pixel stream to the 0-600 MB range.

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -831,6 +831,10 @@ video_mem: video-region@9be82000 {
>  			reg = <0x0 0x9be82000 0x0 0x700000>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};

[Severity: High]
Does this iommu-addresses property block allocations in the 0-600MB range
instead of restricting allocations to it?

During device probe, of_iommu_get_resv_regions() parses this memory-region.
Because iris_resv has an iommu-addresses property but lacks a physical reg
property, it is classified as IOMMU_RESV_RESERVED.

The IOMMU DMA allocator then passes this range to reserve_iova(), which
explicitly excludes the 0-600MB range from the available IOVA pool. 

Will this force subsequent allocations for the non-pixel stream into addresses
above 600MB, resulting in the exact IOMMU faults and device crashes this
patch intends to fix?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=10

Re: [RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `iommu-addresses` without a `reg` property inside the `reserved-memory` node creates an `IOMMU_RESV_RESERVED` region. This explicitly excludes the 0-600MB IOVA range from being allocated, which completely contradicts the patch's stated intention to limit allocations to this range.
--

--- Patch [11]: [RFC PATCH 11/11] arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes ---
commit c2708742df23b3eb0cc33ed47303581c81143971
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8650: Move Iris IOMMUs to child nodes

This patch separates the Iris VPU streams into pixel and non-pixel child
nodes to enforce different IOVA constraints. It attempts to limit the 
non-pixel stream to the 0-600 MB IOVA range by adding a reserved IOVA 
range node.

> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 447b788fcbb96..f9c03de1317f1 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -1849,6 +1849,10 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
>  			reg = <0 0xff800000 0 0x600000>;
>  			no-map;
>  		};
> +
> +		iris_resv: reservation-iris {
> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> +		};

[Severity: High]
Does using iommu-addresses without a reg property in this reserved-memory 
node actually block the 0-600MB range instead of allowing allocations 
within it?

When the non-pixel device is initialized, iommu_dma_init_domain() calls
of_iommu_get_resv_regions(). Because iris_resv lacks a reg property,
this function returns an IOMMU_RESV_RESERVED region for 0-600MB. The 
generic IOMMU layer then calls reserve_iova(), inserting this range into
the rbtree as occupied.

If the 0-600MB range is reserved as blocked, will dma_alloc_attrs() for
the non-pixel stream skip this region entirely and return IOVAs strictly
above 600MB?

This appears to contradict the stated intention of limiting allocations 
to the 0-600MB range, which could guarantee the very device crash the 
patch aims to fix.

[ ... ]

> @@ -5231,6 +5235,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			 */
>  			status = "disabled";
>  
> +			iris_non_pixel: non-pixel {
> +				iommus = <&apps_smmu 0x1940 0x0>;
> +				memory-region = <&iris_resv>;
> +			};
> +
> +			iris_pixel: pixel {
> +				iommus = <&apps_smmu 0x1947 0x0>;
> +			};
> +
>  			iris_opp_table: opp-table {
>  				compatible = "operating-points-v2";

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=11

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Vikash Garodia]

On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
>> VPU hardwares have a limitation where VPU streams are associated with
>> dedicated addressable address range, as illustrated below
>>
>>      +-----------------------------------------------------------+
>>      | Stream A reserved region (600 MB)                         |
>>      | 0x00000000 - 0x25800000                                   |
>>      +-----------------------------------------------------------+
>>      | Stream B reserved region (3.5 GB)                         |
>>      | 0x00000000 - 0xe0000000                                   |
>>      +-----------------------------------------------------------+
>>      | Other reserved regions                                    |
>>      +-----------------------------------------------------------+
>>
>> Mapping a stream outside its expected range can cause unintended
>> behavior, including device crashes, as reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> To address this limitation, the subset of stream/s are now represented as
>> sub nodes, so that they can be associated to the respective addressable
>> range.
>> The limitation could be exposed when running usecase like concurrent
>> video sessions. The binding have been validated with higher concurrent
>> sessions across the SOCs supported under this schema.
>>
>> 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>
>> ---
>>   .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
>>   1 file changed, 63 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>> @@ -91,6 +91,51 @@ properties:
>>     opp-table:
>>       type: object
>>   
>> +  '#address-cells':
>> +    const: 2
>> +
>> +  '#size-cells':
>> +    const: 2
>> +
>> +  non-pixel:
>> +    type: object
>> +    description:
>> +      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
>> +      buffers. Non pixel buffers are compressed and internal buffers.
>> +    properties:
>> +      iommus:
>> +        maxItems: 1
>> +      memory-region:
>> +        maxItems: 1
>> +    required:
>> +      - iommus
>> +      - memory-region
>> +    additionalProperties: false
>> +
>> +  pixel:
>> +    type: object
>> +    description:
>> +      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
>> +      Pixel buffers are uncompressed buffers.
>> +    properties:
>> +      iommus:
>> +        maxItems: 1
>> +    required:
>> +      - iommus
>> +    additionalProperties: false
>> +
>> +  firmware:
>> +    type: object
>> +    description:
>> +      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
>> +      VPU when no hypervisor is present.
>> +    properties:
>> +      iommus:
>> +        maxItems: 1
>> +    required:
>> +      - iommus
>> +    additionalProperties: false
>> +
>>   required:
>>     - compatible
>>     - power-domain-names
>> @@ -98,9 +143,15 @@ required:
>>     - interconnect-names
>>     - resets
>>     - reset-names
>> -  - iommus
>>     - dma-coherent
>>   
>> +oneOf:
>> +  - required:
>> +      - iommus
>> +  - required:
>> +      - non-pixel
>> +      - pixel
>> +
>>   allOf:
>>     - if:
>>         properties:
>> @@ -177,12 +228,21 @@ examples:
>>           resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>>           reset-names = "bus";
>>   
>> -        iommus = <&apps_smmu 0x1940 0x0000>,
>> -                 <&apps_smmu 0x1947 0x0000>;
>>           dma-coherent;
>>   
>>           operating-points-v2 = <&iris_opp_table>;
>>   
>> +        #address-cells = <2>;
>> +        #size-cells = <2>;
> 
> I think you need "ranges;" here. Also an empty line before the subnodes.

Could you please elaborate on what would be the use of "ranges;" in this 
case ?

> 
>> +        iris_non_pixel: non-pixel {
> 
> Drop useless labels.

Ack, labels can be dropped from schema.

> 
>> +            iommus = <&apps_smmu 0x1940 0x0000>;
>> +            memory-region = <&iris_resv>;
>> +        };
>> +
>> +        iris_pixel: pixel {
>> +            iommus = <&apps_smmu 0x1947 0x0000>;
>> +        };
>> +
>>           iris_opp_table: opp-table {
>>               compatible = "operating-points-v2";
>>   
>>
>> -- 
>> 2.34.1
>>
> 

Regards,
Vikash

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Vikash Garodia]

On 7/9/2026 6:33 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
>> The Iris VPU has separate streams with different IOVA constraints. The
>> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
>> pixel stream can use the full IOVA space.
>> Using a single set of IOMMU entries for the Iris node does not describe
>> these per-stream limits and can allow accesses outside the supported
>> range, which may lead to device crashes. One such issue was reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> Add non-pixel and pixel child nodes, move each stream ID to its
>> corresponding child node, and add a reserved IOVA range for the
>> non-pixel stream.
>>
>> 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>
>> ---
>>   arch/arm64/boot/dts/qcom/hamoa.dtsi | 18 ++++++++++++++++--
>>   1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
>>   			hwlocks = <&tcsr_mutex 3>;
>>   			no-map;
>>   		};
>> +
>> +		iris_resv: reservation-iris {
>> +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
>> +		};
>>   	};
>>   
>>   	qup_opp_table_100mhz: opp-table-qup100mhz {
>> @@ -5435,10 +5439,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>>   			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>>   			reset-names = "bus";
>>   
>> -			iommus = <&apps_smmu 0x1940 0>,
>> -				 <&apps_smmu 0x1947 0>;
>>   			dma-coherent;
>>   
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +
>>   			/*
>>   			 * IRIS firmware is signed by vendors, only
>>   			 * enable on boards where the proper signed firmware
>> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>>   			 */
>>   			status = "disabled";
>>   
>> +			iris_non_pixel: non-pixel {
>> +				iommus = <&apps_smmu 0x1940 0x0>;
>> +				memory-region = <&iris_resv>;
>> +			};
>> +
>> +			iris_pixel: pixel {
> 
> Unused label.

Kept it for consistency with others, it can be dropped though.

> Also, shouldn't you specify the IOMMU region for this one
> too?

There is no iova restriction for pixel domain, hence region is not 
needed there.

> 
>> +				iommus = <&apps_smmu 0x1947 0x0>;
>> +			};
>> +
>>   			iris_opp_table: opp-table {
>>   				compatible = "operating-points-v2";
>>   
>>
>> -- 
>> 2.34.1
>>
> 

Regards,
Vikash

Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[Vikash Garodia]

On 7/9/2026 6:44 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
>> Iris platforms use separate context-bank devices for the pixel and
>> non-pixel domains. Add platform hooks to create and destroy those
>> subdevices, and wire them up for the affected platforms.
>>
>> 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/Makefile          |  1 +
>>   .../platform/qcom/iris/iris_platform_sm8550.c      | 71 ++++++++++++++++++++++
>>   .../platform/qcom/iris/iris_platform_sm8550.h      | 24 ++------
>>   .../media/platform/qcom/iris/iris_platform_vpu3x.c |  4 ++
>>   4 files changed, 80 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>> index 48e415cbc4390bc596f6239fefa2a2ad2cd3a2bb..fd6bfe7e786be3f8a4885296fb11ba430ded6fd1 100644
>> --- a/drivers/media/platform/qcom/iris/Makefile
>> +++ b/drivers/media/platform/qcom/iris/Makefile
>> @@ -12,6 +12,7 @@ qcom-iris-objs += iris_buffer.o \
>>                iris_hfi_gen2_packet.o \
>>                iris_hfi_gen2_response.o \
>>                iris_hfi_queue.o \
>> +             iris_platform_sm8550.o \
> 
> No, it's not a separate platform.

This will be dropped, given that the callback would be made generic for 
vpu3x and would be implemented in iris_platform_vpu3x.c

> 
>>                iris_platform_vpu2.o \
>>                iris_platform_vpu3x.o \
>>                iris_power.o \
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_sm8550.c b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..bea904a9249bafe1dfa11ff39155d1930402bf7c
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_sm8550.c
>> @@ -0,0 +1,71 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include "iris_core.h"
>> +#include "iris_platform_common.h"
>> +#include "iris_platform_sm8550.h"
>> +
>> +const char * const sm8550_clk_reset_table[] = { "bus" };
>> +
>> +const struct platform_clk_data sm8550_clk_table[] = {
>> +	{IRIS_AXI_CLK,  "iface"        },
>> +	{IRIS_CTRL_CLK, "core"         },
>> +	{IRIS_HW_CLK,   "vcodec0_core" },
>> +};
>> +
>> +struct platform_inst_caps platform_inst_cap_sm8550 = {
>> +	.min_frame_width = 96,
>> +	.max_frame_width = 8192,
>> +	.min_frame_height = 96,
>> +	.max_frame_height = 8192,
>> +	.max_mbpf = (8192 * 4352) / 256,
>> +	.mb_cycles_vpp = 200,
>> +	.mb_cycles_fw = 489583,
>> +	.mb_cycles_fw_vpp = 66234,
>> +	.max_frame_rate = MAXIMUM_FPS,
>> +	.max_operating_rate = MAXIMUM_FPS,
>> +};
>> +
>> +static int sm8550_init_cb_devs(struct iris_core *core)
>> +{
>> +	struct device *dev;
>> +
>> +	dev = iris_create_cb_dev(core, "non-pixel");
>> +	if (IS_ERR(dev))
>> +		return PTR_ERR(dev);
>> +
>> +	core->np_dev = dev;
>> +
>> +	dev = iris_create_cb_dev(core, "pixel");
>> +	if (IS_ERR(dev))
>> +		goto unreg_np_dev;
>> +
>> +	core->p_dev = dev;
>> +
>> +	return 0;
>> +
>> +unreg_np_dev:
>> +	if (core->np_dev)
>> +		platform_device_unregister(to_platform_device(core->np_dev));
>> +	core->np_dev = NULL;
>> +
>> +	return PTR_ERR(dev);
>> +}
>> +
>> +static void sm8550_deinit_cb_devs(struct iris_core *core)
>> +{
>> +	if (core->p_dev)
>> +		platform_device_unregister(to_platform_device(core->p_dev));
>> +	if (core->np_dev)
>> +		platform_device_unregister(to_platform_device(core->np_dev));
>> +
>> +	core->p_dev = NULL;
>> +	core->np_dev = NULL;
>> +}
>> +
>> +const struct iris_context_bank_ops sm8550_cb_ops = {
> 
> For a long time I have been asking to fix name prefixes. Now you are
> adding one more. No. Please write it as a rule of thumb. All new symbols
> in the iris driver should start with iris_.

Ack

> 
> Moreover, there is nothing sm8550-specific in these hooks. Enable them
> for all VPU3.x platforms uniformly.

Good observation, will change this something like below;
.cb_ops = &vpu3x_cb_ops,

and the callbacks can be added in iris_platform_vpu3x.c


> 
>> +	.init = sm8550_init_cb_devs,
>> +	.deinit = sm8550_deinit_cb_devs,
>> +};
> 

Regards,
Vikash

Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[Bryan O'Donoghue]

On 09/07/2026 13:35, Vikash Garodia wrote:
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> Daniel, who reported the crash issue, have also raised a patch to workaround
> the issue. While the patch partially handles the limitation, it is inefficient
> in a way that it keep iris hardwares away from using the 600MB address space
> for all the different streams.
> 
> To address this limitation, the subset of stream/s are now represented as
> sub nodes, so that they can be associated to the respective addressable
> range.
> In the past, this limitation was tried with iommu-map approach, with iris
> driver dynamically creating the devices. The approach was later concluded
> as an hack to avoid having sub nodes. It was discussed in detail in the
> discussionhttps://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
> 
> It was agreed by maintainers to proceed with sub node approach to address
> the VPU hardware limitation.

What's the addressable range with sub-nodes ?

The original problem you were trying to solve was the total addressable 
size - this other problem here segmenting the linear allocation space is 
adjacent but not the same thing.

Without digging through all of the patches here - my question is does 
the original sub-node addressable space problem get resolved in your 
proposal here ?

---
bod

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Bryan O'Donoghue]

On 09/07/2026 13:35, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.
> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
> 
> 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>
In light of this patch, we should put a pause on Daniel's workaround.

---
bod

Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[Vikash Garodia]

On 7/10/2026 4:05 PM, Bryan O'Donoghue wrote:
> On 09/07/2026 13:35, Vikash Garodia wrote:
>> Mapping a stream outside its expected range can cause unintended
>> behavior, including device crashes, as reported at:
>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>
>> Daniel, who reported the crash issue, have also raised a patch to 
>> workaround
>> the issue. While the patch partially handles the limitation, it is 
>> inefficient
>> in a way that it keep iris hardwares away from using the 600MB address 
>> space
>> for all the different streams.
>>
>> To address this limitation, the subset of stream/s are now represented as
>> sub nodes, so that they can be associated to the respective addressable
>> range.
>> In the past, this limitation was tried with iommu-map approach, with iris
>> driver dynamically creating the devices. The approach was later concluded
>> as an hack to avoid having sub nodes. It was discussed in detail in the
>> discussionhttps://lore.kernel.org/all/c7b956a9-d3e8-4e18- 
>> b780-5d08f5cd2ca1@kernel.org/
>>
>> It was agreed by maintainers to proceed with sub node approach to address
>> the VPU hardware limitation.
> 
> What's the addressable range with sub-nodes ?
> 
> The original problem you were trying to solve was the total addressable 
> size - this other problem here segmenting the linear allocation space is 
> adjacent but not the same thing.
> 
> Without digging through all of the patches here - my question is does 
> the original sub-node addressable space problem get resolved in your 
> proposal here ?

The proposal solves both the problem we have so far - total addressable 
size as well as which segment (or range) in that is _not_ addressable.

Regards,
Vikash

> 
> ---
> bod

Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[Bryan O'Donoghue]

On 10/07/2026 14:36, Vikash Garodia wrote:
>> What's the addressable range with sub-nodes ?
>>
>> The original problem you were trying to solve was the total addressable
>> size - this other problem here segmenting the linear allocation space is
>> adjacent but not the same thing.
>>
>> Without digging through all of the patches here - my question is does
>> the original sub-node addressable space problem get resolved in your
>> proposal here ?
> The proposal solves both the problem we have so far - total addressable
> size as well as which segment (or range) in that is_not_ addressable.

So if I can distill this.

You're proposing two objects in the DT one for each relevant IOMMU SID 
and then the driver will register two different devices to get the full 
range addresses ?

---
bod

Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes

[Vikash Garodia]

On 7/10/2026 7:08 PM, Bryan O'Donoghue wrote:
> On 10/07/2026 14:36, Vikash Garodia wrote:
>>> What's the addressable range with sub-nodes ?
>>>
>>> The original problem you were trying to solve was the total addressable
>>> size - this other problem here segmenting the linear allocation space is
>>> adjacent but not the same thing.
>>>
>>> Without digging through all of the patches here - my question is does
>>> the original sub-node addressable space problem get resolved in your
>>> proposal here ?
>> The proposal solves both the problem we have so far - total addressable
>> size as well as which segment (or range) in that is_not_ addressable.
> 
> So if I can distill this.
> 
> You're proposing two objects in the DT one for each relevant IOMMU SID 
> and then the driver will register two different devices to get the full 
> range addresses ?

yes, alongwith the _non_ addressable range specific to that object, to 
avoid the device crash.
> 
> ---
> bod

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Dmitry Baryshkov]

On Fri, Jul 10, 2026 at 11:32:20AM +0530, Vikash Garodia wrote:
> 
> On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
> > > VPU hardwares have a limitation where VPU streams are associated with
> > > dedicated addressable address range, as illustrated below
> > > 
> > >      +-----------------------------------------------------------+
> > >      | Stream A reserved region (600 MB)                         |
> > >      | 0x00000000 - 0x25800000                                   |
> > >      +-----------------------------------------------------------+
> > >      | Stream B reserved region (3.5 GB)                         |
> > >      | 0x00000000 - 0xe0000000                                   |
> > >      +-----------------------------------------------------------+
> > >      | Other reserved regions                                    |
> > >      +-----------------------------------------------------------+
> > > 
> > > Mapping a stream outside its expected range can cause unintended
> > > behavior, including device crashes, as reported at:
> > > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> > > 
> > > To address this limitation, the subset of stream/s are now represented as
> > > sub nodes, so that they can be associated to the respective addressable
> > > range.
> > > The limitation could be exposed when running usecase like concurrent
> > > video sessions. The binding have been validated with higher concurrent
> > > sessions across the SOCs supported under this schema.
> > > 
> > > 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>
> > > ---
> > >   .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
> > >   1 file changed, 63 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> > > index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
> > > --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> > > +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> > > @@ -91,6 +91,51 @@ properties:
> > >     opp-table:
> > >       type: object
> > > +  '#address-cells':
> > > +    const: 2
> > > +
> > > +  '#size-cells':
> > > +    const: 2
> > > +
> > > +  non-pixel:
> > > +    type: object
> > > +    description:
> > > +      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> > > +      buffers. Non pixel buffers are compressed and internal buffers.
> > > +    properties:
> > > +      iommus:
> > > +        maxItems: 1
> > > +      memory-region:
> > > +        maxItems: 1
> > > +    required:
> > > +      - iommus
> > > +      - memory-region
> > > +    additionalProperties: false
> > > +
> > > +  pixel:
> > > +    type: object
> > > +    description:
> > > +      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> > > +      Pixel buffers are uncompressed buffers.
> > > +    properties:
> > > +      iommus:
> > > +        maxItems: 1
> > > +    required:
> > > +      - iommus
> > > +    additionalProperties: false
> > > +
> > > +  firmware:
> > > +    type: object
> > > +    description:
> > > +      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> > > +      VPU when no hypervisor is present.
> > > +    properties:
> > > +      iommus:
> > > +        maxItems: 1
> > > +    required:
> > > +      - iommus
> > > +    additionalProperties: false
> > > +
> > >   required:
> > >     - compatible
> > >     - power-domain-names
> > > @@ -98,9 +143,15 @@ required:
> > >     - interconnect-names
> > >     - resets
> > >     - reset-names
> > > -  - iommus
> > >     - dma-coherent
> > > +oneOf:
> > > +  - required:
> > > +      - iommus
> > > +  - required:
> > > +      - non-pixel
> > > +      - pixel
> > > +
> > >   allOf:
> > >     - if:
> > >         properties:
> > > @@ -177,12 +228,21 @@ examples:
> > >           resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
> > >           reset-names = "bus";
> > > -        iommus = <&apps_smmu 0x1940 0x0000>,
> > > -                 <&apps_smmu 0x1947 0x0000>;
> > >           dma-coherent;
> > >           operating-points-v2 = <&iris_opp_table>;
> > > +        #address-cells = <2>;
> > > +        #size-cells = <2>;
> > 
> > I think you need "ranges;" here. Also an empty line before the subnodes.
> 
> Could you please elaborate on what would be the use of "ranges;" in this
> case ?

That the subblock has the same address space as the parent. I might be
completely wrong here.

> 
> > 
> > > +        iris_non_pixel: non-pixel {
> > 
> > Drop useless labels.
> 
> Ack, labels can be dropped from schema.
> 
> > 
> > > +            iommus = <&apps_smmu 0x1940 0x0000>;
> > > +            memory-region = <&iris_resv>;
> > > +        };
> > > +
> > > +        iris_pixel: pixel {
> > > +            iommus = <&apps_smmu 0x1947 0x0000>;
> > > +        };
> > > +
> > >           iris_opp_table: opp-table {
> > >               compatible = "operating-points-v2";
> > > 
> > > -- 
> > > 2.34.1
> > > 
> > 
> 
> Regards,
> Vikash
> 

-- 
With best wishes
Dmitry

Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[Dmitry Baryshkov]

On Fri, Jul 10, 2026 at 12:02:46PM +0530, Vikash Garodia wrote:
> 
> 
> On 7/9/2026 6:44 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:52PM +0530, Vikash Garodia wrote:
> > > Iris platforms use separate context-bank devices for the pixel and
> > > non-pixel domains. Add platform hooks to create and destroy those
> > > subdevices, and wire them up for the affected platforms.
> > > 
> > > 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/Makefile          |  1 +
> > >   .../platform/qcom/iris/iris_platform_sm8550.c      | 71 ++++++++++++++++++++++
> > >   .../platform/qcom/iris/iris_platform_sm8550.h      | 24 ++------
> > >   .../media/platform/qcom/iris/iris_platform_vpu3x.c |  4 ++
> > >   4 files changed, 80 insertions(+), 20 deletions(-)
> > > 
> > > +const struct iris_context_bank_ops sm8550_cb_ops = {
> > 
> > For a long time I have been asking to fix name prefixes. Now you are
> > adding one more. No. Please write it as a rule of thumb. All new symbols
> > in the iris driver should start with iris_.
> 
> Ack
> 
> > 
> > Moreover, there is nothing sm8550-specific in these hooks. Enable them
> > for all VPU3.x platforms uniformly.
> 
> Good observation, will change this something like below;
> .cb_ops = &vpu3x_cb_ops,

Please see few lines above, that's a bad name.

Also, is there a reason to introduce a separate struct for those
callbacks? Can we fit them into the existing iris_vpu_ops?

> and the callbacks can be added in iris_platform_vpu3x.c

-- 
With best wishes
Dmitry

Re: [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks

[Dmitry Baryshkov]

On Thu, Jul 09, 2026 at 01:54:18PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> 
> New issues:
> - [High] Unregistering context bank devices in `remove` while V4L2 FDs are open causes DMA API mismatch and IOMMU faults.

Please fix the runtime issues. It's not the first one being reported by
Sashiko. Please go through the previous reviews. I think the nature of
most of lifecycle issues is the same: corectly handling device removal
vs userspace lifecycle.

> - [Medium] Hardcoded platform device ID causes name collision if multiple Iris instances exist.

Dreams... But using PLATFORM_DEVID_AUTO makes sense.

> 
> Pre-existing issues:
> - [High] Missing cancellation of sys_error_handler delayed work leads to Use-After-Free.
> - [High] Use-After-Free on `iris_core` during deferred V4L2 close due to `devm_kzalloc`.
> --
> 

-- 
With best wishes
Dmitry

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Dmitry Baryshkov]

On Fri, Jul 10, 2026 at 11:35:45AM +0530, Vikash Garodia wrote:
> On 7/9/2026 6:33 PM, Dmitry Baryshkov wrote:
> > On Thu, Jul 09, 2026 at 06:05:53PM +0530, Vikash Garodia wrote:
> > > The Iris VPU has separate streams with different IOVA constraints. The
> > > non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> > > pixel stream can use the full IOVA space.
> > > Using a single set of IOMMU entries for the Iris node does not describe
> > > these per-stream limits and can allow accesses outside the supported
> > > range, which may lead to device crashes. One such issue was reported at:
> > > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> > > 
> > > Add non-pixel and pixel child nodes, move each stream ID to its
> > > corresponding child node, and add a reserved IOVA range for the
> > > non-pixel stream.
> > > 
> > > 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>
> > > ---
> > >   arch/arm64/boot/dts/qcom/hamoa.dtsi | 18 ++++++++++++++++--
> > >   1 file changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > index 60f485a4892e062980d01f0b930af4b02f36513c..a2baa2c9f46dc19c3db11dc784358223a035475f 100644
> > > --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
> > >   			hwlocks = <&tcsr_mutex 3>;
> > >   			no-map;
> > >   		};
> > > +
> > > +		iris_resv: reservation-iris {
> > > +			iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> > > +		};
> > >   	};
> > >   	qup_opp_table_100mhz: opp-table-qup100mhz {
> > > @@ -5435,10 +5439,11 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> > >   			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
> > >   			reset-names = "bus";
> > > -			iommus = <&apps_smmu 0x1940 0>,
> > > -				 <&apps_smmu 0x1947 0>;
> > >   			dma-coherent;
> > > +			#address-cells = <2>;
> > > +			#size-cells = <2>;
> > > +
> > >   			/*
> > >   			 * IRIS firmware is signed by vendors, only
> > >   			 * enable on boards where the proper signed firmware
> > > @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> > >   			 */
> > >   			status = "disabled";
> > > +			iris_non_pixel: non-pixel {
> > > +				iommus = <&apps_smmu 0x1940 0x0>;
> > > +				memory-region = <&iris_resv>;
> > > +			};
> > > +
> > > +			iris_pixel: pixel {
> > 
> > Unused label.
> 
> Kept it for consistency with others, it can be dropped though.

Consistency would be to have only the useful labels.

> > Also, shouldn't you specify the IOMMU region for this one
> > too?
> 
> There is no iova restriction for pixel domain, hence region is not needed
> there.

Ok. I was under impression that SIDs are generated based on the address.


-- 
With best wishes
Dmitry

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Bryan O'Donoghue]

On 09/07/2026 13:35, Vikash Garodia wrote:
> VPU hardwares have a limitation where VPU streams are associated with

VPU hardware has

> dedicated addressable address range, as illustrated below
> 
>      +-----------------------------------------------------------+
>      | Stream A reserved region (600 MB)                         |
>      | 0x00000000 - 0x25800000                                   |
>      +-----------------------------------------------------------+
>      | Stream B reserved region (3.5 GB)                         |
>      | 0x00000000 - 0xe0000000                                   |
>      +-----------------------------------------------------------+
>      | Other reserved regions                                    |
>      +-----------------------------------------------------------+
> 
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> To address this limitation, the subset of stream/s are now represented as

To address this bug surely - to me this is a bugfix we are introducing a 
change to stop a crash that leads to a hard reset. Its not a limitation 
its a bug.

> sub nodes, so that they can be associated to the respective addressable
> range.

> The limitation could be exposed when running usecase like concurrent
> video sessions. 

"The bug is readily reproduced when running concurrent video sessions"

The binding have been validated with higher concurrent
> sessions across the SOCs supported under this schema.

The bindings have been

or

The binding has been

> 
> 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>
> ---
>   .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
>   1 file changed, 63 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -91,6 +91,51 @@ properties:
>     opp-table:
>       type: object
> 
> +  '#address-cells':
> +    const: 2
> +
> +  '#size-cells':
> +    const: 2
> +
> +  non-pixel:
> +    type: object
> +    description:
> +      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
> +      buffers. Non pixel buffers are compressed and internal buffers.

Don't describe when it is needed - describe what it is and what it does.

> +    properties:
> +      iommus:
> +        maxItems: 1
> +      memory-region:
> +        maxItems: 1
> +    required:
> +      - iommus
> +      - memory-region
> +    additionalProperties: false
> +
> +  pixel:
> +    type: object
> +    description:
> +      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
> +      Pixel buffers are uncompressed buffers.

Same comment on the necessity of the binding. You're in "justification" 
space here but should be in "information" space i.e. inform the reader 
what as opposed to justify to the reviewer why, which is how these two 
descriptions read.

> +    properties:
> +      iommus:
> +        maxItems: 1
> +    required:
> +      - iommus
> +    additionalProperties: false
> +
> +  firmware:
> +    type: object
> +    description:
> +      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
> +      VPU when no hypervisor is present.

Yes, this is information not justification.

> +    properties:
> +      iommus:
> +        maxItems: 1
> +    required:
> +      - iommus
> +    additionalProperties: false
> +
>   required:
>     - compatible
>     - power-domain-names
> @@ -98,9 +143,15 @@ required:
>     - interconnect-names
>     - resets
>     - reset-names
> -  - iommus
>     - dma-coherent
> 
> +oneOf:
> +  - required:
> +      - iommus
> +  - required:
> +      - non-pixel
> +      - pixel
> +
>   allOf:
>     - if:
>         properties:
> @@ -177,12 +228,21 @@ examples:
>           resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>           reset-names = "bus";
> 
> -        iommus = <&apps_smmu 0x1940 0x0000>,
> -                 <&apps_smmu 0x1947 0x0000>;
>           dma-coherent;
> 
>           operating-points-v2 = <&iris_opp_table>;
> 
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        iris_non_pixel: non-pixel {
> +            iommus = <&apps_smmu 0x1940 0x0000>;
> +            memory-region = <&iris_resv>;
> +        };
> +
> +        iris_pixel: pixel {
> +            iommus = <&apps_smmu 0x1947 0x0000>;
> +        };
> +
>           iris_opp_table: opp-table {
>               compatible = "operating-points-v2";
> 
> 
> --
> 2.34.1
> 

Personally I think this describes a real system behaviour - the question 
is, is it a fixed behaviour - i.e. we _always_ expect to see firmware 
operate this way - if so it should be represented in DT, if not it 
should be represented in a platform descriptor in the driver.

The SIDs are fixed and mean specific things.

It would be possible to encode the SIDs in platform code but, that would 
be unusual.

I think this is a good solution TBH.

---
bod

Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Bryan O'Donoghue]

On 09/07/2026 13:35, Vikash Garodia wrote:
> The Iris VPU has separate streams with different IOVA constraints. The
> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> pixel stream can use the full IOVA space.


> Using a single set of IOMMU entries for the Iris node does not describe
> these per-stream limits and can allow accesses outside the supported
> range, which may lead to device crashes. One such issue was reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> Add non-pixel and pixel child nodes, move each stream ID to its
> corresponding child node, and add a reserved IOVA range for the
> non-pixel stream.
> 
> 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>
The thing of it is, this _is_ a bugfix - perhaps its not one that can be 
backported, actually scratch that, this isn't possible to land in 
-stable realistically.

So what is needed here is a strategy for fixing -stable.

That could be apply Daniel's patch and backport it with Fixes: - with 
mainline then say applying this change and reverting Daniel's patch

or

That could mean some other solution for -stable - up for debate - what's 
not up for debate is this series needs to _address_ what happens to 
stable for all of the target platforms - and then transition mainline to 
the new and shiny way.

That could mean

- Applying Daniel's fix with Fixes: and cc-stable
- That patch needs to be extended to _each_ Iris platform containing
   this bug... all of them I think.
- Updating bindings
- Updating DT with new method simultaneously reverting Daniel's fix

And I do mean doing that in one progressive series - a fixup for 
mainline alone isn't enough.

So we backport a fix from mainline and then make mainline better still. 
Or whatever something like that.

Either way just fixing in mainline is not good enough for each of the 
targeted upstream DTS we need a solution for -stable too, keeping in 
mind new kernels need to work with old bindings.

---
bod

Re: [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu sub nodes

[Vikash Garodia]

On 7/10/2026 9:23 PM, Dmitry Baryshkov wrote:
> On Fri, Jul 10, 2026 at 11:32:20AM +0530, Vikash Garodia wrote:
>>
>> On 7/9/2026 6:20 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jul 09, 2026 at 06:05:47PM +0530, Vikash Garodia wrote:
>>>> VPU hardwares have a limitation where VPU streams are associated with
>>>> dedicated addressable address range, as illustrated below
>>>>
>>>>       +-----------------------------------------------------------+
>>>>       | Stream A reserved region (600 MB)                         |
>>>>       | 0x00000000 - 0x25800000                                   |
>>>>       +-----------------------------------------------------------+
>>>>       | Stream B reserved region (3.5 GB)                         |
>>>>       | 0x00000000 - 0xe0000000                                   |
>>>>       +-----------------------------------------------------------+
>>>>       | Other reserved regions                                    |
>>>>       +-----------------------------------------------------------+
>>>>
>>>> Mapping a stream outside its expected range can cause unintended
>>>> behavior, including device crashes, as reported at:
>>>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>>>
>>>> To address this limitation, the subset of stream/s are now represented as
>>>> sub nodes, so that they can be associated to the respective addressable
>>>> range.
>>>> The limitation could be exposed when running usecase like concurrent
>>>> video sessions. The binding have been validated with higher concurrent
>>>> sessions across the SOCs supported under this schema.
>>>>
>>>> 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>
>>>> ---
>>>>    .../bindings/media/qcom,sm8550-iris.yaml           | 66 +++++++++++++++++++++-
>>>>    1 file changed, 63 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>>> index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..bf4d24ce90bd38666704274390b98be450f708c0 100644
>>>> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
>>>> @@ -91,6 +91,51 @@ properties:
>>>>      opp-table:
>>>>        type: object
>>>> +  '#address-cells':
>>>> +    const: 2
>>>> +
>>>> +  '#size-cells':
>>>> +    const: 2
>>>> +
>>>> +  non-pixel:
>>>> +    type: object
>>>> +    description:
>>>> +      Non pixel context bank is needed when video hardware have distinct iommus for non pixel
>>>> +      buffers. Non pixel buffers are compressed and internal buffers.
>>>> +    properties:
>>>> +      iommus:
>>>> +        maxItems: 1
>>>> +      memory-region:
>>>> +        maxItems: 1
>>>> +    required:
>>>> +      - iommus
>>>> +      - memory-region
>>>> +    additionalProperties: false
>>>> +
>>>> +  pixel:
>>>> +    type: object
>>>> +    description:
>>>> +      Pixel context bank is needed when video hardware have distinct iommus for pixel buffers.
>>>> +      Pixel buffers are uncompressed buffers.
>>>> +    properties:
>>>> +      iommus:
>>>> +        maxItems: 1
>>>> +    required:
>>>> +      - iommus
>>>> +    additionalProperties: false
>>>> +
>>>> +  firmware:
>>>> +    type: object
>>>> +    description:
>>>> +      Firmware context bank represents the firmware processing domain of the VPU. Required to boot
>>>> +      VPU when no hypervisor is present.
>>>> +    properties:
>>>> +      iommus:
>>>> +        maxItems: 1
>>>> +    required:
>>>> +      - iommus
>>>> +    additionalProperties: false
>>>> +
>>>>    required:
>>>>      - compatible
>>>>      - power-domain-names
>>>> @@ -98,9 +143,15 @@ required:
>>>>      - interconnect-names
>>>>      - resets
>>>>      - reset-names
>>>> -  - iommus
>>>>      - dma-coherent
>>>> +oneOf:
>>>> +  - required:
>>>> +      - iommus
>>>> +  - required:
>>>> +      - non-pixel
>>>> +      - pixel
>>>> +
>>>>    allOf:
>>>>      - if:
>>>>          properties:
>>>> @@ -177,12 +228,21 @@ examples:
>>>>            resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>>>>            reset-names = "bus";
>>>> -        iommus = <&apps_smmu 0x1940 0x0000>,
>>>> -                 <&apps_smmu 0x1947 0x0000>;
>>>>            dma-coherent;
>>>>            operating-points-v2 = <&iris_opp_table>;
>>>> +        #address-cells = <2>;
>>>> +        #size-cells = <2>;
>>>
>>> I think you need "ranges;" here. Also an empty line before the subnodes.
>>
>> Could you please elaborate on what would be the use of "ranges;" in this
>> case ?
> 
> That the subblock has the same address space as the parent. I might be
> completely wrong here.

Yes, i explored with the same definition of "ranges", but could not see 
a use of it in our case. I am dropping this for now, unless there are 
suggestion on this on applicability of it in this case.

> 
>>
>>>
>>>> +        iris_non_pixel: non-pixel {
>>>
>>> Drop useless labels.
>>
>> Ack, labels can be dropped from schema.
>>
>>>
>>>> +            iommus = <&apps_smmu 0x1940 0x0000>;
>>>> +            memory-region = <&iris_resv>;
>>>> +        };
>>>> +
>>>> +        iris_pixel: pixel {
>>>> +            iommus = <&apps_smmu 0x1947 0x0000>;
>>>> +        };
>>>> +
>>>>            iris_opp_table: opp-table {
>>>>                compatible = "operating-points-v2";
>>>>
>>>> -- 
>>>> 2.34.1
>>>>
>>>
>>
>> Regards,
>> Vikash
>>
>