diff options
| author | Horatio Zhang <hongkun.zhang@amd.com> | 2026-09-17 17:33:59 +0800 |
|---|---|---|
| committer | Alex Deucher <alexander.deucher@amd.com> | 2026-10-20 12:10:13 -0400 |
| commit | 4e356be7da54f26aa65a7ac641238cbe5e02d439 (patch) | |
| tree | 1af357d2bb10d6fd9ae2375c9e98db99dafb085e /scripts/objdiff | |
| parent | 16df12d7158fb55f20d6e985abd1996cbabab9f8 (diff) | |
| download | linux-4e356be7da54f26aa65a7ac641238cbe5e02d439.tar.gz linux-4e356be7da54f26aa65a7ac641238cbe5e02d439.zip | |
drm/amdgpu: skip the PASID TLB fence for the UALink NPA VM
amdgpu_vm_make_npa() builds the UALink NPA VM on top of
amdgpu_vm_make_compute(), which unconditionally sets need_tlb_fence.
That flag makes amdgpu_vm_tlb_flush() queue an asynchronous PASID based
TLB invalidation after every page table update.
The NPA VM is created by the driver itself in
amdgpu_ualink_manager_start() and never gets a PASID assigned, so
vm->pasid stays 0, which MES cannot resolve on the MMHUB. The invalidation
never completes and MES stays unresponsive for the rest of the probe:
amdgpu: MES(0, 0) failed to respond to msg=INVALIDATE_TLBS
The invalidation is not needed in the first place. An NPA VM is bound to
the reserved NPA VMID and amdgpu_ualink_flush_tlb() already invalidates
that VMID on the MMHUB after every mapping change. Clear need_tlb_fence
for NPA VMs.
Fixes: e05a54573df7 ("drm/amdgpu: Pin page tables in NPA VMs")
Signed-off-by: Horatio Zhang <hongkun.zhang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e419e52cad769df45f496b7621841b25b63235da)
Diffstat (limited to 'scripts/objdiff')
0 files changed, 0 insertions, 0 deletions
