Le 25/08/2025 à 20:31, Jason Gunthorpe a écrit :

On Mon, Aug 25, 2025 at 01:50:16PM -0400, Nicolas Dufresne wrote:

quoted

Jason, the point is that the iommu and the VPU are not separate devices, which
comes with side effects. On RKVDec side, the iommu configuration get resets
whenever a decoding error leads to a VPU "self reset". I can't remember who from
the iommu subsystem suggested that, but the empty domain method was agreed to be

IDK, that seems really goofy too me an defiantly needs to be
extensively documented this is restoring the default with some lore
link of the original suggestion.

quoted

the least invasive way to workaround that issue. I believe Detlev tried multiple
time to add APIs for that before the discussion lead to this path.

You mean this:

https://lore.kernel.org/linux-iommu/20250318152049.14781-1-detlev.casanova@collabora.com/ (local)

Which came back with the same remark I would give:

  Please have some kind of proper reset notifier mechanism - in fact
  with runtime PM could you not already invoke a suspend/resume cycle
  via the device links?

when doing parallel decode suspend/resume are not invoked.

Or another reasonable option:

   Or at worst just export a public interface for the other driver to
   invoke rk_iommu_resume() directly.

Sigh.

An other solution which is working is to call iommu_flush_iotlb_all()
before decoding each frame.
It doesn't require to allocate a domain per decoding context.
Does that sound as a better solution ?

Benjamin

quoted

Benjamin, please improve the naming, comment and description, I agree with Jason
its not completely clear. I'm also surprised that you do that every frame, seems
excessive.

Indeed if it is just error recovery.

quoted

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8c5622f9f7c644e995d013af320b59e4d61b93

This is already merged? And now you want two copies of this? I think
this is a very poor direction..

Jason