kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c, branch v6.6.132

drm/amdgpu: add lock in amdgpu_gart_invalidate_tlb

2024-09-08T05:54:47+00:00

[ Upstream commit 18f2525d31401e5142db95ff3a6ec0f4147be818 ] We need to take the reset domain lock before flush hdp. We can't put the lock inside amdgpu_device_flush_hdp itself because it is used during reset where we already take the write side lock. Signed-off-by: Yunxiang Li Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: use %pad format string for dma_addr_t

2023-06-09T14:50:55+00:00

DMA addresses can be shorter than u64, which results in a broken debug output: drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c: In function 'amdgpu_gart_table_ram_alloc': drivers/gpu/drm/amd/amdgpu/amdgpu.h:41:22: error: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t' {aka 'unsigned int'} [-Werror=format=] drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:146:9: note: in expansion of macro 'dev_info' 146 | dev_info(adev->dev, "%s dma_addr:%llx\n", __func__, dma_addr); Use the special %pad format string and pass the DMA address by reference. Fixes: c9a502e981a9 ("drm/amdgpu: Allocate GART table in RAM for AMD APU") Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher

drm/amdgpu: Allocate GART table in RAM for AMD APU

2023-06-09T13:51:06+00:00

Some AMD APUs may not have a dedicated VRAM. On such platforms the GART table should be allocated on the system memory. When real vram size is zero, place the GART table in system memory and create an SG BO to make it GPU accessible. v2: fix includes Reviewed-by: Felix Kuehling (rajneesh: removed set_memory_wc workaround) Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Harish Kasiviswanathan Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdgpu: add bitmask to iterate vmhubs

2023-06-09T13:40:17+00:00

As the layout of VMHUB definition has been changed to cover multiple XCD/AID case, the original num_vmhubs is not appropriate to do vmhub iteration any more. Drop num_vmhubs and introduce vmhubs_mask instead. v2: switch to the new VMHUB layout v3: use DECLARE_BITMAP to define vmhubs_mask Signed-off-by: Le Ma Reviewed-by: Christian König Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher

drm/amdgpu: check the GART table before invalidating TLB

2022-02-07T23:01:16+00:00

Bypass group programming (utcl2_harvest) aims to forbid UTCL2 to send invalidation command to harvested SE/SA. Once invalidation command comes into harvested SE/SA, SE/SA has no response and system hang. This patch is to add checking if the GART table is already allocated before invalidating TLB. The new procedure is as following: 1. Calling amdgpu_gtt_mgr_init() in amdgpu_ttm_init(). After this step GTT BOs can be allocated, but GART mappings are still ignored. 2. Calling amdgpu_gart_table_vram_alloc() from the GMC code. This allocates the GART backing store. 3. Initializing the hardware, and programming the backing store into VMID0 for all VMHUBs. 4. Calling amdgpu_gtt_mgr_recover() to make sure the table is updated with the GTT allocations done before it was allocated. Signed-off-by: Christian König Signed-off-by: Aaron Liu Acked-by: Huang Rui Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: drop WARN_ON in amdgpu_gart_bind/unbind

2022-01-25T23:00:32+00:00

NULL pointer check has guarded it already. calltrace: amdgpu_ttm_gart_bind+0x49/0xa0 [amdgpu] amdgpu_ttm_alloc_gart+0x13f/0x180 [amdgpu] amdgpu_bo_create_reserved+0x139/0x2c0 [amdgpu] ? amdgpu_ttm_debugfs_init+0x120/0x120 [amdgpu] amdgpu_bo_create_kernel+0x17/0x80 [amdgpu] amdgpu_ttm_init+0x542/0x5e0 [amdgpu] Fixes: 1b08dfb889b2c5 ("drm/amdgpu: remove gart.ready flag") Signed-off-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: remove gart.ready flag

2022-01-20T03:32:47+00:00

That's just a leftover from old radeon days and was preventing CS and GART bindings before the hardware was initialized. But nowdays that is perfectly valid. The only thing we need to warn about are GART binding before the table is even allocated. Signed-off-by: Christian König Reviewed-by: Guchun Chen Signed-off-by: Alex Deucher

drm/amdgpu: recover gart table at resume

2022-01-11T20:44:26+00:00

Get rid off pin/unpin of gart BO at resume/suspend and instead pin only once and try to recover gart content at resume time. This is much more stable in case there is OOM situation at 2nd call to amdgpu_device_evict_resources() while evicting GART table. v3: remove gart recovery from other places v2: pin gart at amdgpu_gart_table_vram_alloc() Reviewed-by: Christian König Signed-off-by: Nirmoy Das Signed-off-by: Alex Deucher

drm/amdgpu: use adev_to_drm for consistency when accessing drm_device

2021-10-08T17:22:13+00:00

adev_to_drm is used everywhere, so improve recent changes when accessing drm_device pointer from amdgpu_device. Signed-off-by: Guchun Chen Acked-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: Put drm_dev_enter/exit outside hot codepath

2021-09-23T19:17:29+00:00

We hit soft hang while doing memory pressure test on one numa system. After a qucik look, this is because kfd invalid/valid userptr memory frequently with process_info lock hold. Looks like update page table mapping use too much cpu time. perf top says below, 75.81% [kernel] [k] __srcu_read_unlock 6.19% [amdgpu] [k] amdgpu_gmc_set_pte_pde 3.56% [kernel] [k] __srcu_read_lock 2.20% [amdgpu] [k] amdgpu_vm_cpu_update 2.20% [kernel] [k] __sg_page_iter_dma_next 2.15% [drm] [k] drm_dev_enter 1.70% [drm] [k] drm_prime_sg_to_dma_addr_array 1.18% [kernel] [k] __sg_alloc_table_from_pages 1.09% [drm] [k] drm_dev_exit So move drm_dev_enter/exit outside gmc code, instead let caller do it. They are gart_unbind, gart_map, vm_clear_bo, vm_update_pdes and gmc_init_pdb0. vm_bo_update_mapping already calls it. Signed-off-by: xinhui pan Reviewed-and-tested-by: Andrey Grodzovsky Signed-off-by: Alex Deucher