Re: [PATCH 00/12] RFC: drm/amdgpu/sdma: Refactor SDMA v4 and older functions to be per-instance

["Timur Kristóf" <timur.kristof@gmail.com>]

On Friday, September 11, 2026 9:00:07 PM Central European Summer Time Alex 
Deucher wrote:
> On Mon, Sep 7, 2026 at 4:40 PM Timur Kristóf <timur.kristof@gmail.com> 
wrote:
> > This series applies on top of my previous series:
> > "Improve existing SDMA queue resets" (currently under review)
> > 
> > Prepare the code for implementing recovery for
> > SDMA v4 and all older SDMA (and SI DMA) versions.
> > Reorganize the SDMA 4.0 code so that the functions that are
> > responsible for managing the SDMA engines take an instance ID
> > as an argument.
> > 
> > This makes it possible to manage the SDMA instances
> > independently of each other, which will enable us to
> > also use these functions to implement resetting and
> > recovering them independently. (The actual recovery
> > implementation will be in a follow-up patch series
> > which I will submit after this one is accepted.)
> 
> This series looks fine to me, although I think I would prefer to apply
> it along with the relevant soft reset changes to avoid churning the
> code until each family is ready.  E.g., apply the cik_sdma refactor
> along with the CIK soft reset support, etc.  Unless you have something
> else in mind.

Thank you Alex.

My plan is the following:

1. I would like to first refactor the functions for every SDMA IP block version 
to be per-instance.
2. Then, I'd like to improve the soft reset code, more specifically the multi-
ring reset helpers and amdgpu_device_ip_soft_reset() to make them aware of IP 
block instances and change SDMA v4.4.2, v5.0 and v5.2 over to use that code.
3. With all of that out of the way, it will be pretty easy to hook up the same 
soft reset mechanism for SI, CIK, VI as well.
4. At that point, we should also consider if we want soft reset for SDMA v6 
and v7. Technically these versions support proper queue reset through the MES, 
but in practice I've seen the MES fail so often that I wouldn't consider it 
stable.

This RFC is basically a prototype for step (1) and only takes care of SDMA v4 
and older just to show how I imagine doing the refactor. If you like this 
direction, I would like to do the same for all IP versions before moving 
forward with soft reset changes and other refactors. I prefer to do this first 
for all IP versions because I think it's important to have consistency within 
the code base regarding how the SDMA is programmed.

What do you think, would that be OK for you?
I understand this causes code churn, sorry about that.

Thanks & best regards,
Timur

> 
> > Timur Kristóf (12):
> >   drm/amdgpu/sdma: Refactor SI DMA functions to be per instance
> >   drm/amdgpu/sdma: Refactor SI DMA clock gating functions to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor CIK SDMA functions to be per instance
> >   drm/amdgpu/sdma: Refactor CIK SDMA clock gating functions to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor SDMA v2.4 functions to be per instance
> >   drm/amdgpu/sdma: Refactor SDMA v2.4 golden registers to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor SDMA v3.0 functions to be per instance
> >   drm/amdgpu/sdma: Refactor SDMA v3.0 clock gating functions to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor SDMA v3.0 golden registers to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor SDMA v4.0 functions to be per instance
> >   drm/amdgpu/sdma: Refactor SDMA v4.0 clock gating functions to be
> >   
> >     per-instance
> >   
> >   drm/amdgpu/sdma: Refactor SDMA v4.0 golden registers to be
> >   
> >     per-instance
> >  
> >  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  | 322 +++++++-------
> >  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 232 +++++-----
> >  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 561 ++++++++++++++----------
> >  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 577 +++++++++++++++----------
> >  drivers/gpu/drm/amd/amdgpu/si_dma.c    | 160 ++++---
> >  5 files changed, 1043 insertions(+), 809 deletions(-)
> > 
> > --
> > 2.55.0