[PATCH v2 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt

[PATCH v2 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt

[Matheus Tagliari]

Hardware H.264 encoding with the VCE block on SI GPUs (radeon driver)
hangs the GPU after a few dozen frames.  I hit it with the KDE Plasma
RDP server, which encodes through VAAPI, and reproduced it with a
plain "ffmpeg -vaapi_device ... -c:v h264_vaapi" test on a Radeon HD
8870M (Cape Verde).

The VCE1 code never enables the VCE trap interrupt and the SI (and
Trinity) interrupt handlers do not process it, unlike the CIK code and
amdgpu.  Patch 1 adds the handlers, patch 2 enables the interrupt.

Results on Debian 6.12.113 (see patch 2 for numbers): hang before,
none after, and 34 fps instead of ~4 fps for the workaround that avoids
the hang.  The KDE RDP server (KRDP) itself, driven by a local FreeRDP
client, now encodes on the VCE ring for several minutes (about 40
fences per second on ring 6 in the radeon_fence_emit tracepoint) with a
clean kernel log.

Two caveats:

 - I have not worked out why the missing interrupt turns into ring
   lockups instead of only added latency.  What I know is that the
   hang needs the VCE ring to wait on a hardware semaphore (disabling
   only the waiting side, or both sides, of radeon_vce_semaphore_emit()
   avoids it) and that handling the interrupt makes it go away with
   the semaphores left enabled.  If someone knows why, I would be glad
   to improve the commit message.
 - The Trinity/Richland change has not been tested on that hardware.

The series was developed and tested on Debian's 6.12.113 with the
radeon module built out of tree.  It applies cleanly on drm-next
(fad06cf), where drivers/gpu/drm/radeon builds without warnings (W=1,
allmodconfig) both after patch 1 and with the whole series.

v1: https://lore.kernel.org/r/20261021114122.94008-1-mptagliari@gmail.com

Changes in v2:
 - Patch 2: only enable VCE_SYS_INT_EN for VCE1 (family < CHIP_BONAIRE).
   vce_v1_0_start() is also reached on CIK (vce_v1_0_init() from cik.c,
   kv_dpm), where the register is at a different offset and is already
   enabled by vce_v2_0_resume(); v1 would have written the VCE1 offset
   there.  Thanks to the automated review of v1 for pointing this out.
 - Patch 1: unchanged.

Matheus Tagliari (2):
  drm/radeon: process the VCE interrupt on SI and Trinity
  drm/radeon/vce1: enable the VCE trap interrupt

 drivers/gpu/drm/radeon/evergreen.c | 14 ++++++++++++++
 drivers/gpu/drm/radeon/si.c        | 14 ++++++++++++++
 drivers/gpu/drm/radeon/sid.h       |  2 ++
 drivers/gpu/drm/radeon/vce_v1_0.c  |  9 +++++++++
 4 files changed, 39 insertions(+)


base-commit: fad06cfaf385787b9ffa2f73f049d42dbe1de57f
-- 
2.47.3

[PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Matheus Tagliari]

radeon_vce_fence_emit() ends every VCE fence with VCE_CMD_TRAP, which
raises the VCE trap interrupt (IH src_id 167).  cik_irq_process()
handles it by calling radeon_fence_process() for the matching VCE ring,
but si_irq_process() and evergreen_irq_process(), which serve the other
ASICs with VCE1 (SI and Trinity/Richland), have no case for it.

Add the same handling.  The trap interrupt is not enabled on these
ASICs yet, so this does not change behaviour on its own; the next patch
enables it.

The SI part was tested together with the next patch.  The Trinity part
mirrors the CIK and SI code and has not been tested on Trinity/Richland
hardware.

Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4")
Cc: stable@vger.kernel.org
Signed-off-by: Matheus Tagliari <mptagliari@gmail.com>
---
 drivers/gpu/drm/radeon/evergreen.c | 14 ++++++++++++++
 drivers/gpu/drm/radeon/si.c        | 14 ++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
index 3cbc6eedb..eb94916c8 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4847,6 +4847,20 @@ int evergreen_irq_process(struct radeon_device *rdev)
 			drm_dbg(ddev, "IH: UVD int: 0x%08x\n", src_data);
 			radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
 			break;
+		case 167: /* VCE */
+			drm_dbg(ddev, "IH: VCE int: 0x%08x\n", src_data);
+			switch (src_data) {
+			case 0:
+				radeon_fence_process(rdev, TN_RING_TYPE_VCE1_INDEX);
+				break;
+			case 1:
+				radeon_fence_process(rdev, TN_RING_TYPE_VCE2_INDEX);
+				break;
+			default:
+				drm_err(ddev, "Unhandled interrupt: %d %d\n", src_id, src_data);
+				break;
+			}
+			break;
 		case 146:
 		case 147:
 			addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 4681ff286..af3c4026d 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6347,6 +6347,20 @@ int si_irq_process(struct radeon_device *rdev)
 			DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
 			radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
 			break;
+		case 167: /* VCE */
+			DRM_DEBUG("IH: VCE int: 0x%08x\n", src_data);
+			switch (src_data) {
+			case 0:
+				radeon_fence_process(rdev, TN_RING_TYPE_VCE1_INDEX);
+				break;
+			case 1:
+				radeon_fence_process(rdev, TN_RING_TYPE_VCE2_INDEX);
+				break;
+			default:
+				DRM_ERROR("Unhandled interrupt: %d %d\n", src_id, src_data);
+				break;
+			}
+			break;
 		case 146:
 		case 147:
 			addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
-- 
2.47.3

[PATCH v2 2/2] drm/radeon/vce1: enable the VCE trap interrupt

[Matheus Tagliari]

vce_v2_0 sets VCE_SYS_INT_TRAP_INTERRUPT_EN in VCE_SYS_INT_EN so that
the VCE_CMD_TRAP emitted after each fence raises an interrupt.  The
VCE1 code, used by SI and Trinity/Richland, never does, and amdgpu's
vce_v1_0 does (mmVCE_SYS_INT_EN, 0x8340, i.e. byte offset 0x20d00 on
SI).  VCE fences are therefore never processed from the interrupt
handler and are only noticed when a fence wait times out.

Enable the trap interrupt at the end of vce_v1_0_start().  CIK also
goes through vce_v1_0_start() (via vce_v1_0_init() and kv_dpm), but has
VCE_SYS_INT_EN at a different offset and already enables it in
vce_v2_0_resume(), so only do it for VCE1, i.e. before CHIP_BONAIRE.

Observed on a Radeon HD 8870M (Cape Verde, 1002:6821) with VCE firmware
50.0.1, Mesa 25.0.7 radeonsi and ffmpeg h264_vaapi on Debian 6.12.113:

 - Stock driver: the encode hangs after a few dozen frames ("ring 0
   stalled", "ring 3 stalled", "GPU lockup"), and the reset does not
   recover ("failed VCE resume (-22)", "ring 0 test failed").
 - With the hardware ring semaphores of the VCE ring disabled as a
   workaround, the hang is gone but encoding runs at 3.9 fps
   (~256 ms per frame), consistent with fences being noticed only by
   timeouts.
 - With this series: 640x360 for 1800 frames, 1280x720 for 900 frames
   and 1920x1080 for 600 frames, all in real time with no decode
   errors, and 191 fps at 720p / 91 fps at 1080p unthrottled.  Four
   runtime suspend/resume cycles with an encode in between also
   worked.  No lockup, reset, WARNING or error in the kernel log, with
   DPM and runtime PM enabled.

Trinity/Richland takes the same path and is covered by the previous
patch, but I have no such hardware to test.  CIK is not affected.

Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4")
Cc: stable@vger.kernel.org
Signed-off-by: Matheus Tagliari <mptagliari@gmail.com>
---
 drivers/gpu/drm/radeon/sid.h      | 2 ++
 drivers/gpu/drm/radeon/vce_v1_0.c | 9 +++++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h
index f9267b026..ba322de84 100644
--- a/drivers/gpu/drm/radeon/sid.h
+++ b/drivers/gpu/drm/radeon/sid.h
@@ -1878,6 +1878,8 @@
 #define	DMA_PACKET_NOP					  0xf
 
 #define VCE_STATUS					0x20004
+#define VCE_SYS_INT_EN					0x20d00
+#define		VCE_SYS_INT_TRAP_INTERRUPT_EN		(1 << 3)
 #define VCE_VCPU_CNTL					0x20014
 #define		VCE_CLK_EN				(1 << 0)
 #define VCE_VCPU_CACHE_OFFSET0				0x20024
diff --git a/drivers/gpu/drm/radeon/vce_v1_0.c b/drivers/gpu/drm/radeon/vce_v1_0.c
index bdfbcf14b..09fc1572a 100644
--- a/drivers/gpu/drm/radeon/vce_v1_0.c
+++ b/drivers/gpu/drm/radeon/vce_v1_0.c
@@ -350,6 +350,15 @@ int vce_v1_0_start(struct radeon_device *rdev)
 		return r;
 	}
 
+	/*
+	 * Enable the trap interrupt so that VCE fences are processed.
+	 * CIK also gets here but has VCE_SYS_INT_EN elsewhere and enables
+	 * it in vce_v2_0_resume().
+	 */
+	if (rdev->family < CHIP_BONAIRE)
+		WREG32_P(VCE_SYS_INT_EN, VCE_SYS_INT_TRAP_INTERRUPT_EN,
+			 ~VCE_SYS_INT_TRAP_INTERRUPT_EN);
+
 	return 0;
 }
 
-- 
2.47.3

Re: [PATCH v2 0/2] drm/radeon: fix VCE1 encoding on SI by handling the VCE interrupt

[Alex Deucher]

On Thu, Oct 22, 2026 at 9:21 AM Matheus Tagliari <mptagliari@gmail.com> wrote:
>
> Hardware H.264 encoding with the VCE block on SI GPUs (radeon driver)
> hangs the GPU after a few dozen frames.  I hit it with the KDE Plasma
> RDP server, which encodes through VAAPI, and reproduced it with a
> plain "ffmpeg -vaapi_device ... -c:v h264_vaapi" test on a Radeon HD
> 8870M (Cape Verde).
>
> The VCE1 code never enables the VCE trap interrupt and the SI (and
> Trinity) interrupt handlers do not process it, unlike the CIK code and
> amdgpu.  Patch 1 adds the handlers, patch 2 enables the interrupt.
>
> Results on Debian 6.12.113 (see patch 2 for numbers): hang before,
> none after, and 34 fps instead of ~4 fps for the workaround that avoids
> the hang.  The KDE RDP server (KRDP) itself, driven by a local FreeRDP
> client, now encodes on the VCE ring for several minutes (about 40
> fences per second on ring 6 in the radeon_fence_emit tracepoint) with a
> clean kernel log.
>
> Two caveats:
>
>  - I have not worked out why the missing interrupt turns into ring
>    lockups instead of only added latency.  What I know is that the
>    hang needs the VCE ring to wait on a hardware semaphore (disabling
>    only the waiting side, or both sides, of radeon_vce_semaphore_emit()
>    avoids it) and that handling the interrupt makes it go away with
>    the semaphores left enabled.  If someone knows why, I would be glad
>    to improve the commit message.
>  - The Trinity/Richland change has not been tested on that hardware.
>
> The series was developed and tested on Debian's 6.12.113 with the
> radeon module built out of tree.  It applies cleanly on drm-next
> (fad06cf), where drivers/gpu/drm/radeon builds without warnings (W=1,
> allmodconfig) both after patch 1 and with the whole series.
>
> v1: https://lore.kernel.org/r/20261021114122.94008-1-mptagliari@gmail.com
>
> Changes in v2:
>  - Patch 2: only enable VCE_SYS_INT_EN for VCE1 (family < CHIP_BONAIRE).
>    vce_v1_0_start() is also reached on CIK (vce_v1_0_init() from cik.c,
>    kv_dpm), where the register is at a different offset and is already
>    enabled by vce_v2_0_resume(); v1 would have written the VCE1 offset
>    there.  Thanks to the automated review of v1 for pointing this out.
>  - Patch 1: unchanged.
>
> Matheus Tagliari (2):
>   drm/radeon: process the VCE interrupt on SI and Trinity
>   drm/radeon/vce1: enable the VCE trap interrupt

Series is:
Acked-by: Alex Deucher <alexander.deucher@amd.com>
and applied.

Alex

>
>  drivers/gpu/drm/radeon/evergreen.c | 14 ++++++++++++++
>  drivers/gpu/drm/radeon/si.c        | 14 ++++++++++++++
>  drivers/gpu/drm/radeon/sid.h       |  2 ++
>  drivers/gpu/drm/radeon/vce_v1_0.c  |  9 +++++++++
>  4 files changed, 39 insertions(+)
>
>
> base-commit: fad06cfaf385787b9ffa2f73f049d42dbe1de57f
> --
> 2.47.3
>

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Christian König]

On 10/22/26 13:47, Matheus Tagliari wrote:
> radeon_vce_fence_emit() ends every VCE fence with VCE_CMD_TRAP, which
> raises the VCE trap interrupt (IH src_id 167).  cik_irq_process()
> handles it by calling radeon_fence_process() for the matching VCE ring,
> but si_irq_process() and evergreen_irq_process(), which serve the other
> ASICs with VCE1 (SI and Trinity/Richland), have no case for it.
> 
> Add the same handling.  The trap interrupt is not enabled on these
> ASICs yet, so this does not change behaviour on its own; the next patch
> enables it.
> 
> The SI part was tested together with the next patch.  The Trinity part
> mirrors the CIK and SI code and has not been tested on Trinity/Richland
> hardware.
> 
> Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4")
> Cc: stable@vger.kernel.org

Please drop that, we really don't want this to be backported.

> Signed-off-by: Matheus Tagliari <mptagliari@gmail.com>

With the CC: stable tag dropped Acked-by: Christian König <christian.koenig@amd.com>

> ---
>  drivers/gpu/drm/radeon/evergreen.c | 14 ++++++++++++++
>  drivers/gpu/drm/radeon/si.c        | 14 ++++++++++++++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
> index 3cbc6eedb..eb94916c8 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -4847,6 +4847,20 @@ int evergreen_irq_process(struct radeon_device *rdev)
>  			drm_dbg(ddev, "IH: UVD int: 0x%08x\n", src_data);
>  			radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
>  			break;
> +		case 167: /* VCE */
> +			drm_dbg(ddev, "IH: VCE int: 0x%08x\n", src_data);
> +			switch (src_data) {
> +			case 0:
> +				radeon_fence_process(rdev, TN_RING_TYPE_VCE1_INDEX);
> +				break;
> +			case 1:
> +				radeon_fence_process(rdev, TN_RING_TYPE_VCE2_INDEX);
> +				break;
> +			default:
> +				drm_err(ddev, "Unhandled interrupt: %d %d\n", src_id, src_data);
> +				break;
> +			}
> +			break;
>  		case 146:
>  		case 147:
>  			addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index 4681ff286..af3c4026d 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -6347,6 +6347,20 @@ int si_irq_process(struct radeon_device *rdev)
>  			DRM_DEBUG("IH: UVD int: 0x%08x\n", src_data);
>  			radeon_fence_process(rdev, R600_RING_TYPE_UVD_INDEX);
>  			break;
> +		case 167: /* VCE */
> +			DRM_DEBUG("IH: VCE int: 0x%08x\n", src_data);
> +			switch (src_data) {
> +			case 0:
> +				radeon_fence_process(rdev, TN_RING_TYPE_VCE1_INDEX);
> +				break;
> +			case 1:
> +				radeon_fence_process(rdev, TN_RING_TYPE_VCE2_INDEX);
> +				break;
> +			default:
> +				DRM_ERROR("Unhandled interrupt: %d %d\n", src_id, src_data);
> +				break;
> +			}
> +			break;
>  		case 146:
>  		case 147:
>  			addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Matheus Tagliari]

> Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4")
> Cc: stable@vger.kernel.org
> Please drop that, we really don't want this to be backported.

Understood, no backport.

Alex, you already applied v2.  Could you drop the "Cc: stable" line
from both patches when you add the tags, or would you rather have a
v3 from me?

Christian, do you also want the Fixes: tag gone?  I kept it because it
points at where the problem comes from, but if I remember the stable
rules correctly, commits with a Fixes: tag can still be picked up for
backporting without a Cc: stable, so it may matter if the goal is to
keep this out of the stable trees.

Thanks,
Matheus

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Timur Kristóf]

On Mon, 2026-10-26 at 09:22 +0100, Christian König wrote:
> On 10/22/26 13:47, Matheus Tagliari wrote:
> > radeon_vce_fence_emit() ends every VCE fence with VCE_CMD_TRAP,
> > which
> > raises the VCE trap interrupt (IH src_id 167).  cik_irq_process()
> > handles it by calling radeon_fence_process() for the matching VCE
> > ring,
> > but si_irq_process() and evergreen_irq_process(), which serve the
> > other
> > ASICs with VCE1 (SI and Trinity/Richland), have no case for it.
> > 
> > Add the same handling.  The trap interrupt is not enabled on these
> > ASICs yet, so this does not change behaviour on its own; the next
> > patch
> > enables it.
> > 
> > The SI part was tested together with the next patch.  The Trinity
> > part
> > mirrors the CIK and SI code and has not been tested on
> > Trinity/Richland
> > hardware.
> > 
> > Fixes: a918efab631a ("drm/radeon: add VCE 1.0 support v4")
> > Cc: stable@vger.kernel.org
> 
> Please drop that, we really don't want this to be backported.

Hi Christian & Matheus,

Why wouldn't want this patch to be backported?

AFAIU the main case for this patch set is to fix VCE1 for people who
are still stuck on the old radeon KMD on old distros that ship an LTS
kernel version.

Timur

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Matheus Tagliari]

Hi Timur, Christian,

Thanks for the input, Timur.

To be clear, I'm not opposed to a backport. Fixing VCE1 for people stuck
on the radeon driver with an LTS kernel is exactly the case that made me
look into this in the first place. But my goal is only to help, and as I
said before, I do not want to push a change you don't want.

Christian, if you'd rather keep this out of stable, I'll drop the
"Cc: stable" tag in v3 and leave the decision to you. If there is a
specific concern behind it (risk of regressions on other SI/Trinity
parts, say), I'd be glad to hear it. I can also try to address it, for
example with more testing, so that a backport can be reconsidered later.

On that note, the SI part was tested on real hardware together with
patch 2, but the Trinity/Richland part only mirrors the existing CIK and
SI handling and has not been tested on hardware. If anyone has a
Trinity or Richland machine and can run a VCE encode with the series
applied, a Tested-by would help for both the review and any backport
discussion.

Either way, I'll respin v3 with whatever you both prefer.

Thanks,
Matheus

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Christian König]

On 10/27/26 01:15, Matheus Tagliari wrote:
> Hi Timur, Christian,
> 
> Thanks for the input, Timur.
> 
> To be clear, I'm not opposed to a backport. Fixing VCE1 for people stuck
> on the radeon driver with an LTS kernel is exactly the case that made me
> look into this in the first place. But my goal is only to help, and as I
> said before, I do not want to push a change you don't want.
> 
> Christian, if you'd rather keep this out of stable, I'll drop the
> "Cc: stable" tag in v3 and leave the decision to you. If there is a
> specific concern behind it (risk of regressions on other SI/Trinity
> parts, say), I'd be glad to hear it. I can also try to address it, for
> example with more testing, so that a backport can be reconsidered later.

I was part of the Trinity bringup back (I still have the engineering sample here :) and I filled a full swear jar bringing VCE up on that HW.

Interrupts were definitely not working correctly back then.

I have no idea when they were fixed but I want to avoid that people start streaming that this change made their system not boot any more and we are forced to revert a patch on stable kernels everywhere.

> On that note, the SI part was tested on real hardware together with
> patch 2, but the Trinity/Richland part only mirrors the existing CIK and
> SI handling and has not been tested on hardware. If anyone has a
> Trinity or Richland machine and can run a VCE encode with the series
> applied, a Tested-by would help for both the review and any backport
> discussion.

I'm pretty sure my engineering sample doesn't work any more. That was an A0 stepping and those boards are only stitched together to work for a few weeks/month during initial HW bringup.

Regards,
Christian.

> Either way, I'll respin v3 with whatever you both prefer.
> 
> Thanks,
> Matheus

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Timur Kristóf]

On Tue, 2026-10-27 at 11:21 +0100, Christian König wrote:
> On 10/27/26 01:15, Matheus Tagliari wrote:
> > Hi Timur, Christian,
> > 
> > Thanks for the input, Timur.
> > 
> > To be clear, I'm not opposed to a backport. Fixing VCE1 for people
> > stuck
> > on the radeon driver with an LTS kernel is exactly the case that
> > made me
> > look into this in the first place. But my goal is only to help, and
> > as I
> > said before, I do not want to push a change you don't want.
> > 
> > Christian, if you'd rather keep this out of stable, I'll drop the
> > "Cc: stable" tag in v3 and leave the decision to you. If there is a
> > specific concern behind it (risk of regressions on other SI/Trinity
> > parts, say), I'd be glad to hear it. I can also try to address it,
> > for
> > example with more testing, so that a backport can be reconsidered
> > later.
> 
> I was part of the Trinity bringup back (I still have the engineering
> sample here :) and I filled a full swear jar bringing VCE up on that
> HW.
> 
> Interrupts were definitely not working correctly back then.
> 
> I have no idea when they were fixed but I want to avoid that people
> start streaming that this change made their system not boot any more
> and we are forced to revert a patch on stable kernels everywhere.

@Christian
Are you saying that you are worried about the backport because it may
regress Trinity?

@Matheus
Would it be possible to only use the interrupt on SI and not on Trinity
so as to alleviate Christian's worry?

Thanks,
Timur

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Alex Deucher]

On Tue, Oct 27, 2026 at 10:31 AM Timur Kristóf <timur.kristof@gmail.com> wrote:
>
> On Tue, 2026-10-27 at 11:21 +0100, Christian König wrote:
> > On 10/27/26 01:15, Matheus Tagliari wrote:
> > > Hi Timur, Christian,
> > >
> > > Thanks for the input, Timur.
> > >
> > > To be clear, I'm not opposed to a backport. Fixing VCE1 for people
> > > stuck
> > > on the radeon driver with an LTS kernel is exactly the case that
> > > made me
> > > look into this in the first place. But my goal is only to help, and
> > > as I
> > > said before, I do not want to push a change you don't want.
> > >
> > > Christian, if you'd rather keep this out of stable, I'll drop the
> > > "Cc: stable" tag in v3 and leave the decision to you. If there is a
> > > specific concern behind it (risk of regressions on other SI/Trinity
> > > parts, say), I'd be glad to hear it. I can also try to address it,
> > > for
> > > example with more testing, so that a backport can be reconsidered
> > > later.
> >
> > I was part of the Trinity bringup back (I still have the engineering
> > sample here :) and I filled a full swear jar bringing VCE up on that
> > HW.
> >
> > Interrupts were definitely not working correctly back then.
> >
> > I have no idea when they were fixed but I want to avoid that people
> > start streaming that this change made their system not boot any more
> > and we are forced to revert a patch on stable kernels everywhere.
>
> @Christian
> Are you saying that you are worried about the backport because it may
> regress Trinity?
>
> @Matheus
> Would it be possible to only use the interrupt on SI and not on Trinity
> so as to alleviate Christian's worry?

I've committed the patches already.  I don't think the stable really
matters that much.  If there is a problem, we can revert.

Alex

Re: [PATCH v2 1/2] drm/radeon: process the VCE interrupt on SI and Trinity

[Matheus Tagliari]

Hi Alex, Timur, Christian,

Thanks Alex for picking these up, and Christian for the Trinity
background.

Timur, yes, that is possible. The only place where Trinity/Richland
gets the interrupt enabled is the family check in vce_v1_0_start() in
patch 2.  Today it reads "rdev->family < CHIP_BONAIRE", which also
matches CHIP_ARUBA.  Narrowing it to

	if (rdev->family >= CHIP_TAHITI && rdev->family < CHIP_BONAIRE)

enables it on Tahiti, Pitcairn, Verde, Oland and Hainan only, and
leaves Trinity/Richland (and CIK) as they were.  I built vce_v1_0.o
with that change against 6.12 and checked the gate against the
radeon_family enum: SI on, ARUBA and CIK off.  On SI the generated
code is the same register write I tested on the Cape Verde card, so
the earlier results still apply there.  I cannot test the Trinity side.

The handling added to evergreen_irq_process() by patch 1 stays
harmless on Trinity: with the trap interrupt left disabled it is
never raised.

Since the series is already applied, I did not want to send a v3 on
top of it unasked.  If Christian would still prefer to keep Trinity
out of the picture, especially for stable, I can send this as a
small follow-up against the current tree right away.  Otherwise I
will leave it as it is.

Thanks,
Matheus