On 2026-10-02 11:54, Philip Yang wrote:
Flush the NPA VMID TLB once, right after the NPA VM page directory base
address is programmed, so no stale translation is left behind from a
previous page table.
After that the TLB has nothing cached for the NPA VMID, so mapping a new
NPA address doesn't need a flush. Drop the flush from the metadata NPA
mapping and from amdgpu_ualink_map_npa_addr(), which never updates valid
page directory entries, it only maps a newly allocated NPA address.
The NPA unmap paths keep the TLB flush.
Signed-off-by: Philip Yang <[email protected]>
Sounds reasonable. But the removal of the TLB flush in map_npa_addr
needs to be regression-tested before it can be submitted.
Reviewed-by: Felix Kuehling <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
index 758265670340..f49404a6dee4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ualink.c
@@ -2148,9 +2148,6 @@ static int amdgpu_ualink_map_npa_addr(struct
amdgpu_device *adev, u64 npa_addr,
amdgpu_ualink_unreserve_npa_vm_and_bos(adev, &exec);
- /* TLB flush may be needed after updated page directories */
- amdgpu_ualink_flush_tlb(adev, TLB_FLUSH_HEAVYWEIGHT);
-
return 0;
unmap_npa:
@@ -4162,6 +4159,8 @@ int amdgpu_ualink_manager_start(struct amdgpu_device
*adev)
adev->mmhub.funcs->setup_vm_pt_regs(adev, adev->vm_manager.npa_vmid,
amdgpu_gmc_pd_addr(adev->ualink.npa_vm.root.bo));
+ amdgpu_ualink_flush_tlb(adev, TLB_FLUSH_HEAVYWEIGHT);
+
xa_init(&adev->ualink.exp_xa);
xa_init(&adev->ualink.imp_xa);
xa_init(&adev->ualink.handle_invalid_xa);
@@ -5056,8 +5055,6 @@ static int amdgpu_ualink_metadata_npa_mapping(struct
amdgpu_device *adev)
dev_dbg(adev->dev, "failed %d to dma fence wait\n", r);
}
- amdgpu_ualink_flush_tlb(adev, TLB_FLUSH_HEAVYWEIGHT);
-
amdgpu_ualink_unreserve_npa_vm_and_bos(adev, &exec);
return 0;
