On 29/01/2026 16:39, Alex Deucher wrote:
On Thu, Jan 29, 2026 at 11:27 AM Tvrtko Ursulin <[email protected]> wrote:
On 29/01/2026 04:34, Alex Deucher wrote:
wptr is a 64 bit value and we need to update the
full value, not just 32 bits. Align with what we
already do for KCQs.
Signed-off-by: Alex Deucher <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index e9254ec3b6417..ef7d91a4437ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -6883,7 +6883,7 @@ static int gfx_v10_0_kgq_init_queue(struct amdgpu_ring
*ring, bool reset)
memcpy_toio(mqd, adev->gfx.me.mqd_backup[mqd_idx],
sizeof(*mqd));
/* reset the ring */
ring->wptr = 0;
- *ring->wptr_cpu_addr = 0;
+ atomic64_set((atomic64_t *)ring->wptr_cpu_addr, 0);
For my education could I ask if this just about writing the 64-bit value
or the atomic part is also important?
Just the 64 bit value in this case.
Thank you, it was a bit confusing for me. Even in the context of what
you explained to Timur that pre-gfx9 wptr is 32-bit, becauase when I
looked into for example the gfx8 code, I saw it doing a mix of 64- and
32-bit writes.
I guess the layout of the write back info block thingy is fully
software/driver defined which is why this is not an issue?
Would it be worth getting rid of the atomics to lessen the confusion and
attempt to somehow make this area more self-documenting?
Regards,
Tvrtko
