On Mon, Jun 23, 2025 at 05:39:27PM +0200, Benjamin Gaignard wrote:
The Verisilicon IOMMU hardware block can be found in combinationIt broadly seems OK to me
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.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@xxxxxxxxxxxxx>
---
change in version 4:
- Kconfig dependencies
- Fix the remarks done by Jason and Robin: locking, clocks, macros
probing, pm_runtime, atomic allocation.
Though I did notice this:
+static struct iommu_domain *vsi_iommu_domain_alloc_paging(struct device *dev)So we store the iommu in the domain? And use the iommu->lock all over
+{
+ struct vsi_iommu *iommu = dev_iommu_priv_get(dev);
+ struct vsi_iommu_domain *vsi_domain;
+
+ vsi_domain = kzalloc(sizeof(*vsi_domain), GFP_KERNEL);
+ if (!vsi_domain)
+ return NULL;
+
+ vsi_domain->iommu = iommu;
the place
+static int vsi_iommu_attach_device(struct iommu_domain *domain,But here we don't check that the domain matches the iommu of dev.
+ struct device *dev)
+{
+ struct vsi_iommu *iommu = dev_iommu_priv_get(dev);
+ struct vsi_iommu_domain *vsi_domain = to_vsi_domain(domain);
+ unsigned long flags;
+ int ret = 0;
+
+ ret = pm_runtime_resume_and_get(iommu->dev);
+ if (ret < 0)
+ return ret;
+
+ spin_lock_irqsave(&iommu->lock, flags);
+ /* iommu already attached */
+ if (iommu->domain == domain)
+ goto unlock;
This seems a bit weird to me, I didn't quite get why the domain uses
iommu->lock instead of just having its own per-domain lock?
But if it does use iommu->lock then this does need to prevent using
domains with the wrong iommu because the also use the wrong lock and
then this:
+Is not safe?
+ vsi_iommu_enable(iommu, domain);
+ list_add_tail(&iommu->node, &vsi_domain->iommus);
Jason