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
Subject: Re: [PATCH v13 3/6] iommu: Add verisilicon IOMMU driver
Date: Tue, 24 Mar 2026 15:46:20 +0000 [thread overview]
Message-ID: <acKxzGk1Z541yoZ4@willie-the-truck> (raw)
In-Reply-To: <20260216095144.107356-4-benjamin.gaignard@collabora.com>
On Mon, Feb 16, 2026 at 10:51:35AM +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>
> ---
> MAINTAINERS | 8 +
> drivers/iommu/Kconfig | 11 +
> drivers/iommu/Makefile | 1 +
> drivers/iommu/vsi-iommu.c | 794 ++++++++++++++++++++++++++++++++++++++
> include/linux/vsi-iommu.h | 21 +
> 5 files changed, 835 insertions(+)
> create mode 100644 drivers/iommu/vsi-iommu.c
> create mode 100644 include/linux/vsi-iommu.h
[...]
> +static size_t vsi_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
> + size_t size, size_t count, struct iommu_iotlb_gather *gather)
> +{
> + struct vsi_iommu_domain *vsi_domain = to_vsi_domain(domain);
> + dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
> + unsigned long flags;
> + phys_addr_t pt_phys;
> + u32 dte;
> + u32 *pte_addr;
> + size_t unmap_size = 0;
> +
> + spin_lock_irqsave(&vsi_domain->lock, flags);
> +
> + dte = vsi_domain->dt[vsi_iova_dte_index(iova)];
> + /* Just return 0 if iova is unmapped */
> + if (!vsi_dte_is_pt_valid(dte))
> + goto unlock;
> +
> + pt_phys = vsi_dte_pt_address(dte);
> + pte_addr = (u32 *)phys_to_virt(pt_phys) + vsi_iova_pte_index(iova);
> + pte_dma = pt_phys + vsi_iova_pte_index(iova) * sizeof(u32);
> + unmap_size = vsi_iommu_unmap_iova(vsi_domain, pte_addr, pte_dma, size);
> +
> +unlock:
> + spin_unlock_irqrestore(&vsi_domain->lock, flags);
> +
> + return unmap_size;
> +}
I still think you need TLB invalidation here.
I looked at the downstream code that you linked to and it litters the
invalidation in the callers via mpp_iommu_flush_tlb(), which tend to
invalidate _before_ starting an operation. That's very likely buggy and
certainly not something we want upstream.
The unmap routine should do the invalidation so that, when it returns,
the pages really are unmapped from the device (assuming strict mode).
I know you said that you tried to add invalidation here and it "didn't
work", but that's not something I can really help you with.
Will
next prev parent reply other threads:[~2026-03-24 15:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 9:51 [PATCH v13 0/6] Add support for Verisilicon IOMMU used by media Benjamin Gaignard
2026-02-16 9:51 ` [PATCH v13 1/6] dt-bindings: vendor-prefixes: Add Verisilicon Benjamin Gaignard
2026-02-16 9:51 ` [PATCH v13 2/6] dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU Benjamin Gaignard
2026-02-16 9:51 ` [PATCH v13 3/6] iommu: Add verisilicon IOMMU driver Benjamin Gaignard
2026-03-24 15:46 ` Will Deacon [this message]
2026-03-24 16:28 ` Benjamin Gaignard
2026-03-25 16:36 ` Will Deacon
2026-02-16 9:51 ` [PATCH v13 4/6] media: verisilicon: AV1: Restore IOMMU context before decoding a frame Benjamin Gaignard
2026-02-16 9:51 ` [PATCH v13 5/6] arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588 Benjamin Gaignard
2026-02-16 9:51 ` [PATCH v13 6/6] arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588 Benjamin Gaignard
2026-02-16 15:16 ` Krzysztof Kozlowski
2026-02-16 15:30 ` Benjamin Gaignard
2026-02-16 15:32 ` Krzysztof Kozlowski
2026-02-16 15:33 ` Krzysztof Kozlowski
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=acKxzGk1Z541yoZ4@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=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