On 4/1/26 08:59, Zhang, Jesse(Jie) wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > >> -----Original Message----- >> From: Koenig, Christian <[email protected]> >> Sent: Tuesday, March 31, 2026 7:57 PM >> To: Zhang, Jesse(Jie) <[email protected]>; [email protected] >> Cc: Deucher, Alexander <[email protected]> >> Subject: Re: [PATCH 1/2] drm/amdgpu/sdma_v6.0: enable WPTR polling for UMQ >> SDMA MQD >> >> >> >> On 3/31/26 11:53, Jesse Zhang wrote: >>> UMQ SDMA queues can stall when only F32/MCU WPTR polling is enabled in the >> MQD RB control configuration. >>> Enable WPTR_POLL_ENABLE in sdma_v6_0 init so hardware can reliably >>> observe WB write pointer updates while keeping the existing doorbell path >> enabled. >>> >>> This fixes UMQ SDMA submissions timing out on subsequent packets where >> wptr/rptr no longer advance. >>> >>> Signed-off-by: Jesse Zhang <[email protected]> >>> --- >>> drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c >>> b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c >>> index b005672f2f96..622518483c6e 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c >>> @@ -863,6 +863,7 @@ static int sdma_v6_0_mqd_init(struct amdgpu_device >> *adev, void *mqd, >>> order_base_2(prop->queue_size / 4) << >> SDMA0_QUEUE0_RB_CNTL__RB_SIZE__SHIFT | >>> 1 << >> SDMA0_QUEUE0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT | >>> 4 << >> SDMA0_QUEUE0_RB_CNTL__RPTR_WRITEBACK_TIMER__SHIFT | >>> + 1 << >> SDMA0_QUEUE0_RB_CNTL__WPTR_POLL_ENABLE__SHIFT | >> >> This enabled WPTR polling for the kernel queue which is clearly not correct. > This patch will not affect the SDMA kernel queue. > the kernel ring path configures SDMA queues via register writes; the UMQ path > supplies a firmware-facing MQD built by sdma_*_mqd_init().
Ah! So the MQD path just uses the SDMA0_QUEUE0_RB_CNTL_* macros to fill in the MQD values the MES should use. That makes a bit more sense, yes. But that still doesn't explain why that should fix the SDMA issue we are seeing? Regards, Christian. > > Thanks > Jesse >> >> My educated guess is that this only works around the problem because it >> keeps the >> SDMA awake. >> >> Regards, >> Christian. >> >>> 1 << >> SDMA0_QUEUE0_RB_CNTL__F32_WPTR_POLL_ENABLE__SHIFT; >>> >>> m->sdmax_rlcx_rb_base = lower_32_bits(prop->hqd_base_gpu_addr >> 8); >
