kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c, branch v6.19.11

drm/amdgpu: Drop MMIO_REMAP domain bit and keep it Internal

2026-02-26T23:00:59+00:00

[ Upstream commit 96e97a562d067a6d867862db79864cc66aae99c2 ] "AMDGPU_GEM_DOMAIN_MMIO_REMAP" - Never activated as UAPI and it turned out that this was to inflexible. Allocate the MMIO_REMAP buffer object as a regular GEM BO and explicitly move it into the fixed AMDGPU_PL_MMIO_REMAP placement at the TTM level. This avoids relying on GEM domain bits for MMIO_REMAP, keeps the placement purely internal, and makes the lifetime and pinning of the global MMIO_REMAP BO explicit. The BO is pinned in TTM so it cannot be migrated or evicted. The corresponding free path relies on normal DRM teardown ordering, where no further user ioctls can access the global BO once TTM teardown begins. v2 (Srini): - Updated patch title. - Drop use of AMDGPU_GEM_DOMAIN_MMIO_REMAP in amdgpu_ttm.c. The MMIO_REMAP domain bit is removed from UAPI, so keep the MMIO_REMAP BO allocation domain-less (bp.domain = 0) and rely on the TTM placement (AMDGPU_PL_MMIO_REMAP) for backing/pinning. - Keep fdinfo/mem-stats visibility for MMIO_REMAP by classifying BOs based on bo->tbo.resource->mem_type == AMDGPU_PL_MMIO_REMAP, since the domain bit is removed. v3: Squash patches #1 & #3 Fixes: 056132483724 ("drm/amdgpu/uapi: Introduce AMDGPU_GEM_DOMAIN_MMIO_REMAP") Fixes: 2a7a794eb82c ("drm/amdgpu/ttm: Allocate/Free 4K MMIO_REMAP Singleton") Cc: Alex Deucher Cc: Christian König Cc: Leo Liu Cc: Ruijing Dong Cc: David (Ming Qiang) Wu Signed-off-by: Srinivasan Shanmugam Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu/ttm: Pin 4K MMIO_REMAP Singleton BO at Init v2

2026-02-26T23:00:59+00:00

[ Upstream commit de8955508b72f8a88afc3f2cbb62334d5f79ccc3 ] MMIO_REMAP (HDP flush page) is a hardware I/O window exposed via a PCI BAR. It must not migrate or be evicted. Allocate a single 4 KB GEM BO in AMDGPU_GEM_DOMAIN_MMIO_REMAP during TTM initialization when the hardware exposes a remap bus address and the host page size is <= 4 KiB. Reserve the BO and pin it at the TTM level so it remains fixed for its lifetime. No CPU mapping is established here. On teardown, reserve, unpin, and free the BO if present. This prepares the object to be shared (e.g., via dma-buf) without triggering placement changes or no CPU-access migration v2: Added extra NULL checks Suggested-by: Christian König Suggested-by: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Stable-dep-of: 96e97a562d06 ("drm/amdgpu: Drop MMIO_REMAP domain bit and keep it Internal") Signed-off-by: Sasha Levin

Merge tag 'amd-drm-next-6.19-2025-12-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

2025-12-02T23:43:49+00:00

amd-drm-next-6.19-2025-12-02: amdgpu: - Unified MES fix - SMU 11 unbalanced irq fix - Fix for driver reloading on APUs - pp_table sysfs fix - Fix memory leak in fence handling - HDMI fix - DC cursor fixes - eDP panel parsing fix - Brightness fix - DC analog fixes - EDID retry fixes - UserQ fixes - RAS fixes - IP discovery fix - Add missing locking in amdgpu_ttm_access_memory_sdma() - Smart Power OLED fix - PRT and page fault fixes for GC 6-8 - VMID reservation fix - ACP platform device fix - Add missing vm fault handling for GC 11-12 - VPE fix amdkfd: - Partitioning fix Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patch.msgid.link/20251202220101.2039347-1-alexander.deucher@amd.com

drm/amdgpu: add missing lock to amdgpu_ttm_access_memory_sdma

2025-12-02T16:01:21+00:00

Users of ttm entities need to hold the gtt_window_lock before using them to guarantee proper ordering of jobs. Cc: stable@vger.kernel.org Fixes: cb5cc4f573e1 ("drm/amdgpu: improve debug VRAM access performance using sdma") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher

Merge tag 'drm-misc-next-2025-12-01-1' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2025-12-02T08:09:08+00:00

Extra drm-misc-next for v6.19-rc1: UAPI Changes: - Add support for drm colorop pipeline. - Add COLOR PIPELINE plane property. - Add DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE. Cross-subsystem Changes: - Attempt to use higher order mappings in system heap allocator. - Always taint kernel with sw-sync. Core Changes: - Small fixes to drm/gem. - Support emergency restore to drm-client. - Allocate and release fb_info in single place. - Rework ttm pipelined eviction fence handling. Driver Changes: - Support the drm color pipeline in vkms, amdgfx. - Add NVJPG driver for tegra. - Assorted small fixes and updates to rockchip, bridge/dw-hdmi-qp, panthor. - Add ASL CS5263 DP-to-HDMI simple bridge. - Add and improve support for G LD070WX3-SL01 MIPI DSI, Samsung LTL106AL0, Samsung LTL106AL01, Raystar RFF500F-AWH-DNN, Winstar WF70A8SYJHLNGA, Wanchanglong w552946aaa, Samsung SOFEF00, Lenovo X13s panel. - Add support for it66122 to it66121. - Support mali-G1 gpu in panthor. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patch.msgid.link/aa5cbd50-7676-4a59-bbed-e8428af86804@linux.intel.com

drm/amdgpu: use ttm_resource_manager_cleanup

2025-11-26T15:49:40+00:00

Rather than open-coding it. Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Link: https://lore.kernel.org/r/20251121101315.3585-3-pierre-eric.pelloux-prayer@amd.com Signed-off-by: Christian König

drm/amdgpu/ttm: Fix crash when handling MMIO_REMAP in PDE flags

2025-11-19T22:34:15+00:00

The MMIO_REMAP BO is a special 4K IO page that does not have a ttm_tt behind it. However, amdgpu_ttm_tt_pde_flags() was treating it like normal TT/doorbell/preempt memory and unconditionally accessed ttm->caching. For the MMIO_REMAP BO, ttm is NULL, so this leads to a NULL pointer dereference when computing PDE flags. Fix this by checking that ttm is non-NULL before reading ttm->caching. This prevents the crash for MMIO_REMAP and also makes the code more defensive if other BOs ever come through without a ttm_tt. Fixes: fb5a52dbe9fe ("drm/amdgpu: Implement TTM handling for MMIO_REMAP placement") Suggested-by: Jesse Zhang Suggested-by: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Jesse Zhang Tested-by: Jesse Zhang Signed-off-by: Alex Deucher

drm/amdgpu/ttm: Use GART helper to map VRAM pages (v2)

2025-11-12T02:54:17+00:00

Use the GART helper function introduced in the previous commit to map the VRAM pages of the transfer window to GART. No functional changes, just code cleanup. Split this into a separate commit to make it easier to bisect, in case there are problems in the future. Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher

Merge tag 'drm-misc-next-2025-11-05-1' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2025-11-07T02:41:26+00:00

drm-misc-next for v6.19-rc1: UAPI Changes: - Add userptr support to ivpu. - Add IOCTL's for resource and telemetry data in amdxdna. Core Changes: - Improve some atomic state checking handling. - drm/client updates. - Use forward declarations instead of including drm_print.h - RUse allocation flags in ttm_pool/device_init and allow specifying max useful pool size and propagate ENOSPC. - Updates and fixes to scheduler and bridge code. - Add support for quirking DisplayID checksum errors. Driver Changes: - Assorted cleanups and fixes in rcar-du, accel/ivpu, panel/nv3052cf, sti, imxm, accel/qaic, accel/amdxdna, imagination, tidss, sti, panthor, vkms. - Add Samsung S6E3FC2X01 DDIC/AMS641RW, Synaptics TDDI series DSI, TL121BVMS07-00 (IL79900A) panels. - Add mali MediaTek MT8196 SoC gpu support. - Add etnaviv GC8000 Nano Ultra VIP r6205 support. - Document powervr ge7800 support in the devicetree. Signed-off-by: Dave Airlie From: Maarten Lankhorst Link: https://patch.msgid.link/5afae707-c9aa-4a47-b726-5e1f1aa7a106@linux.intel.com

drm/amdgpu: Configure max beneficial TTM pool allocation order

2025-10-31T09:14:50+00:00

Let the TTM pool allocator know that we can afford for it to expend less effort for satisfying contiguous allocations larger than 2MiB. The latter is the maximum relevant PTE entry size and the driver and hardware are happy to get larger blocks only opportunistically. Signed-off-by: Tvrtko Ursulin Cc: Alex Deucher Cc: Christian König Cc: Thadeu Lima de Souza Cascardo Reviewed-by: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20251020115411.36818-6-tvrtko.ursulin@igalia.com