Re: [PATCH 02/11] media: iris: Add iris vpu bus support and register it with iommu_buses

[Dmitry Baryshkov]

On Mon, Apr 20, 2026 at 07:32:23PM +0530, Vishnu Reddy wrote:
> 
> On 4/17/2026 11:49 PM, Dmitry Baryshkov wrote:
> > On Fri, Apr 17, 2026 at 08:29:21PM +0530, Vishnu Reddy wrote:
> >> apologies for re-sending (earlier responses was rejected due to HTML format)
> > Ugh.
> >
> >> On 4/17/2026 8:22 PM, Vishnu Reddy wrote:
> >>> On 4/14/2026 8:44 PM, Dmitry Baryshkov wrote:
> >>>> On Tue, Apr 14, 2026 at 10:29:58AM +0530, Vishnu Reddy wrote:
> >>>>> From: Vikash Garodia<vikash.garodia@xxxxxxxxxxxxxxxx>
> >>>>>
> >>>>> Add a dedicated iris VPU bus type and register it into the iommu_buses
> >>>>> list. Iris devices require their own bus so that each device can run its
> >>>>> own dma_configure() logic.
> >>>> This really tells nothing, unless one has full context about the Iris
> >>>> needs. Start by describing the issue (that the device needs to have
> >>>> multiple devices talking to describe IOMMUs / VAs for several hardware
> >>>> functions), then continue by describing what is needed from the IOMMU
> >>>> subsys.
> >>> This series handles firmware device which do not require multiple
> >>> devices part.
> >>> given this device need for specific IOMMU configuration, I'll update the
> >>> description
> >>> accordingly.
> >>>
> >>>>> Signed-off-by: Vikash Garodia<vikash.garodia@xxxxxxxxxxxxxxxx>
> >>>>> Signed-off-by: Vishnu Reddy<busanna.reddy@xxxxxxxxxxxxxxxx>
> >>>>> ---
> >>>>>   drivers/iommu/iommu.c                           |  4 ++++
> >>>>>   drivers/media/platform/qcom/iris/Makefile       |  4 ++++
> >>>>>   drivers/media/platform/qcom/iris/iris_vpu_bus.c | 32 +++++++++++++++++++++++++
> >>>>>   include/linux/iris_vpu_bus.h                    | 13 ++++++++++
> >>>> How are you supposed to merge this? Through IOMMU tree? Through venus
> >>>> tree? Can we add one single bus to the IOMMU code and use it for Iris,
> >>>> Venus, FastRPC, host1x and all other device drivers which require
> >>>> per-device DMA configuration?
> >>> Separating out the bus definition and the Iris driver handling would
> >>> provide a
> >>> cleaner merge path.
> > Then why wasn't it done from the ground up?
> >
> >>>> Your colleagues from the FastRPC team posted a very similar code few
> >>>> weeks ago and got exactly the same feedback. Is there a reason why your
> >>>> teams don't sync on the IOMMU parts at all?
> >>> I would admit that I missed to review that, thank you for bringing that
> >>> discussion.
> >>> FastRPC patches generalizes the handling for host1x, FastRPC and the
> >>> same can be
> >>> extended for Iris. I have left few comments there.
> >>>
> >>>>>   4 files changed, 53 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> >>>>> index 61c12ba78206..d8ed6ef70ecd 100644
> >>>>> --- a/drivers/iommu/iommu.c
> >>>>> +++ b/drivers/iommu/iommu.c
> >>>>> @@ -13,6 +13,7 @@
> >>>>>   #include <linux/bug.h>
> >>>>>   #include <linux/types.h>
> >>>>>   #include <linux/init.h>
> >>>>> +#include <linux/iris_vpu_bus.h>
> >>>>>   #include <linux/export.h>
> >>>>>   #include <linux/slab.h>
> >>>>>   #include <linux/errno.h>
> >>>>> @@ -179,6 +180,9 @@ static const struct bus_type * const iommu_buses[] = {
> >>>>>   #ifdef CONFIG_CDX_BUS
> >>>>>   	&cdx_bus_type,
> >>>>>   #endif
> >>>>> +#if IS_ENABLED(CONFIG_VIDEO_QCOM_IRIS)
> >>>>> +	&iris_vpu_bus_type,
> >>>>> +#endif
> >>>>>   };
> >>>>>   /*
> >>>>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
> >>>>> index 2abbd3aeb4af..6f4052b98491 100644
> >>>>> --- a/drivers/media/platform/qcom/iris/Makefile
> >>>>> +++ b/drivers/media/platform/qcom/iris/Makefile
> >>>>> @@ -31,3 +31,7 @@ qcom-iris-objs += iris_platform_gen1.o
> >>>>>   endif
> >>>>>   obj-$(CONFIG_VIDEO_QCOM_IRIS) += qcom-iris.o
> >>>>> +
> >>>>> +ifdef CONFIG_VIDEO_QCOM_IRIS
> >>>>> +obj-y += iris_vpu_bus.o
> >>>>> +endif
> >>>>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_bus.c b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> >>>>> new file mode 100644
> >>>>> index 000000000000..b51bb4b82b0e
> >>>>> --- /dev/null
> >>>>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> >>>>> @@ -0,0 +1,32 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0-only
> >>>>> +/*
> >>>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> >>>>> + */
> >>>>> +
> >>>>> +#include <linux/device.h>
> >>>>> +#include <linux/of_device.h>
> >>>>> +
> >>>>> +#include "iris_platform_common.h"
> >>>>> +
> >>>>> +static int iris_vpu_bus_dma_configure(struct device *dev)
> >>>>> +{
> >>>>> +	const u32 *f_id = dev_get_drvdata(dev);
> >>>>> +
> >>>>> +	if (!f_id)
> >>>>> +		return -ENODEV;
> >>>>> +
> >>>>> +	return of_dma_configure_id(dev, dev->parent->of_node, true, f_id);
> >>>> I think it was discussed that this is not enough. Some of devices need
> >>>> multiple function IDs.
> >>> In this glymur series we are following the legacy way of handling IOMMUs
> >>> and does not
> >>> require multi map.
> > Why can't we land the version that has multiple entries? It's as if the
> > teams are totally not in sync. The corresponding version is in works, it
> > has been implemented, etc.
> The main idea is to introduce firmware stream ID with iommu-map, while keeping the
> other stream IDs described in legacy iommus way.
> or, are you suggesting that, going forward, we should have VPU stream IDs described
> _only_ with iommu-map for any new dts/bindings?

I thought it was the plan, to keep only one (or zero?) IOMMU stream in
iommus and move the rest to iommu-map.

> 
> Thanks,
> Vishnu Reddy.
> 

-- 
With best wishes
Dmitry