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

[Benjamin Gaignard]

Le 25/08/2025 à 20:31, Jason Gunthorpe a écrit :
> On Mon, Aug 25, 2025 at 01:50:16PM -0400, Nicolas Dufresne wrote:
>
>> 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.
>
>> 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/
>
> 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

>
>> 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.
>
>> [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
>