Re: [PATCH v7 4/6] media: verisilicon: AV1: Restore IOMMU context before decoding a frame

Le mardi 26 août 2025 à 09:41 -0300, Jason Gunthorpe a écrit :

On Tue, Aug 26, 2025 at 11:52:37AM +0200, Benjamin Gaignard wrote:

quoted

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

quoted

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.

It was a proposal for an error recovery path.

quoted

quoted

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.

That was already proposed and shot down, it makes no sense at all use
to use flushing to reset the registers because the HW weirdly lost
them, and flushing should never happen outside mapping contexts.

If the HW is really resetting the iommu registers after every frame
that is really just painfully broken, and makes me wonder if it really
should be an iommu subsystem driver at all if it is so tightly coupled
to the computing HW. :\

Like we wouldn't try to put a GPU MMU into the iommu subsystem though
they do fairly similar things.

I didn't mention, but this is obviously close to the same IOMMU wrapped inside
etnaviv (same company making it). Note that for media driver, drivers in the
iommu subsystem are very convenient, they just work usually (except when they
don't like with codecs). I'm pretty sure rkmmu is also used by Panfrost, so I
suppose not all GPU IOMMU lives in GPU drivers (I could be wrong). Its one
instance per block, but the same programming interface. Note that we do have an
in-driver iommu implementation in the RGA2 driver.

If we can agree on solutions for this problem, which seems slightly different on
RK compared to VSI IOMMU, it will be quite beneficial to not have to override
all the media allocation ops, and re-implement rkmmu, vsimmu in every driver
needing this block. The VSI mmu could be used similarly to how the rkmmu is
used, meaning we'd have to copy its implementation in every driver. If we could
find out more accuratly how this is suppose to work it would be great, I feel we
don't really understand what is going on yet. Once that done, we can port rkvdec
driver with the unified solution.

The empty domain approach was used since there was no solution that came out
over a year, and users these days expect concurrent decoding to work. So yes,
its not all pretty, but its the best we found until this type of hardware
behaviour gets an API for that is commonly agreed.

Main question is shall we block on merging the VSI IOMMU driver for that reason
? Its there anything in the IOMMU driver that still needs more work ?

cheers,
Nicolas

p.s. RK means Rockchip, VSI means Verisilicon, the company behind Vivante GPU