public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: joro@8bytes.org, robin.murphy@arm.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, heiko@sntech.de,
	nicolas.dufresne@collabora.com, p.zabel@pengutronix.de,
	mchehab@kernel.org, iommu@lists.linux.dev,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-media@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCH v11 3/7] iommu: Add verisilicon IOMMU driver
Date: Tue, 13 Jan 2026 16:10:51 +0000	[thread overview]
Message-ID: <aWZui-rn5RDPwpEO@willie-the-truck> (raw)
In-Reply-To: <20260107101005.84039-4-benjamin.gaignard@collabora.com>

Hi Benjamin,

Thanks for posting a v11.

On Wed, Jan 07, 2026 at 11:09:53AM +0100, Benjamin Gaignard wrote:
> The Verisilicon IOMMU hardware block can be found in combination
> with Verisilicon hardware video codecs (encoders or decoders) on
> different SoCs.
> Enable it will allow us to use non contiguous memory allocators
> for Verisilicon video codecs.
> If both decoder and this iommu driver are compiled has modules
> there is undefined symboles issues so this iommu driver could
> only be compiled has built-in.
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> ---
> changes in version 11:
> - Fix dependency issue when decoder driver is build as module.
> 
>  drivers/iommu/Kconfig     |  11 +
>  drivers/iommu/Makefile    |   1 +
>  drivers/iommu/vsi-iommu.c | 808 ++++++++++++++++++++++++++++++++++++++
>  include/linux/vsi-iommu.h |  21 +
>  4 files changed, 841 insertions(+)
>  create mode 100644 drivers/iommu/vsi-iommu.c
>  create mode 100644 include/linux/vsi-iommu.h

Based on your reply to v9:

https://lore.kernel.org/all/0eff8b1a-c45f-47b1-a871-59f4a0101f0f@collabora.com/

I took another look at this to see whether it had changed significantly
from v6 when compared to the rockchip driver. Sadly, they still look
very similar to me and I continue to suspect that the hardware is a
derivative. I really don't understand why having a shared implementation
of the default domain ops is difficult or controversial. Have you tried
to write it?

However, given that nobody from the Rockchip side has contributed to the
discussion and you claim that this is a distinct piece of IP, I don't
want to block the merging of the driver by leaving the conversation
hanging.

There is still one thing I don't understand (which, amusingly, the
rockchip driver doesn't seem to suffer from):

> +static void vsi_iommu_flush_tlb_all(struct iommu_domain *domain)
> +{
> +	struct vsi_iommu_domain *vsi_domain = to_vsi_domain(domain);
> +	struct list_head *pos;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&vsi_domain->lock, flags);
> +
> +	list_for_each(pos, &vsi_domain->iommus) {
> +		struct vsi_iommu *iommu;
> +		int ret;
> +
> +		iommu = list_entry(pos, struct vsi_iommu, node);
> +		ret = pm_runtime_resume_and_get(iommu->dev);
> +		if (ret < 0)
> +			continue;
> +
> +		spin_lock(&iommu->lock);
> +
> +		writel(VSI_MMU_BIT_FLUSH, iommu->regs + VSI_MMU_FLUSH_BASE);
> +		writel(0, iommu->regs + VSI_MMU_FLUSH_BASE);
> +
> +		spin_unlock(&iommu->lock);
> +		pm_runtime_put_autosuspend(iommu->dev);
> +	}
> +
> +	spin_unlock_irqrestore(&vsi_domain->lock, flags);
> +}

[...]

> +static const struct iommu_ops vsi_iommu_ops = {
> +	.identity_domain = &vsi_identity_domain,
> +	.release_domain = &vsi_identity_domain,
> +	.domain_alloc_paging = vsi_iommu_domain_alloc_paging,
> +	.of_xlate = vsi_iommu_of_xlate,
> +	.probe_device = vsi_iommu_probe_device,
> +	.release_device = vsi_iommu_release_device,
> +	.device_group = generic_single_device_group,
> +	.owner = THIS_MODULE,
> +	.default_domain_ops = &(const struct iommu_domain_ops) {
> +		.attach_dev		= vsi_iommu_attach_device,
> +		.map_pages		= vsi_iommu_map,
> +		.unmap_pages		= vsi_iommu_unmap,
> +		.flush_iotlb_all	= vsi_iommu_flush_tlb_all,

This has no callers and so your unmap routine appears to be broken.

Will

  reply	other threads:[~2026-01-13 16:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07 10:09 [PATCH v11 0/7] Add support for Verisilicon IOMMU used by media Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 1/7] dt-bindings: vendor-prefixes: Add Verisilicon Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 2/7] dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 3/7] iommu: Add verisilicon IOMMU driver Benjamin Gaignard
2026-01-13 16:10   ` Will Deacon [this message]
2026-01-13 16:25     ` Benjamin Gaignard
2026-01-14 12:59       ` Will Deacon
2026-01-14 13:10         ` Benjamin Gaignard
2026-01-19 12:32           ` Will Deacon
2026-01-19 14:03             ` Benjamin Gaignard
2026-01-21 12:51               ` Will Deacon
2026-01-21 13:50                 ` Benjamin Gaignard
2026-01-23 17:14                   ` Will Deacon
2026-01-26  9:03                     ` Benjamin Gaignard
2026-01-26 14:19                       ` Will Deacon
2026-01-26 14:46                         ` Benjamin Gaignard
2026-02-16 10:03                         ` Benjamin Gaignard
2026-01-18  9:41     ` Jörg Rödel
2026-01-19  7:51       ` Benjamin Gaignard
2026-01-19  8:56         ` Jörg Rödel
2026-01-19 10:28       ` Benjamin Gaignard
2026-01-19 14:06         ` Jörg Rödel
2026-01-07 10:09 ` [PATCH v11 4/7] MAINTAINERS: Add entry for Verisilicon " Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 5/7] media: verisilicon: AV1: Restore IOMMU context before decoding a frame Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 6/7] arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588 Benjamin Gaignard
2026-01-07 10:09 ` [PATCH v11 7/7] arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588 Benjamin Gaignard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWZui-rn5RDPwpEO@willie-the-truck \
    --to=will@kernel.org \
    --cc=benjamin.gaignard@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox