summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
12 daysmm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio()Nico Pache
Patch series "mm: fix PMD level mTHP accounting bugs", v2. While running selftests I noticed the PMD level per-mTHP stats (nr_anon) remained elevated after each run. After further investigation I noticed this accounting error occurs for both the migration.private_anon_htlb_test and the HMM tests. In the HMM case this is due to folio_add_new_anon_rmap() incrementing the mTHP stats, but never containing a corresponding decrement in free_zone_device_folio(). We solve this by making sure to decrement the counter when freeing device memory. In the migration case, we are incrementing this counter without first checking whether this folio is a hugetlb folio, which relies on a separate accounting system. We solve this by adding the proper hugetlb check before incrementing this counter. With these changes in place, the two tests no longer cause elevated PMD level accounting issues. This patch (of 2): When a zone device folio is mapped as anonymous, folio_add_new_anon_rmap() increments MTHP_STAT_NR_ANON. The corresponding decrement lives in __free_pages_prepare() in page_alloc.c, but zone device folios are freed via free_zone_device_folio() which never calls __free_pages_prepare(). This causes nr_anon to remain permanently elevated after zone device folios are freed. Add the missing mod_mthp_stat() decrement to free_zone_device_folio() so that the counter is properly balanced. Link: https://lore.kernel.org/20260717064502.1980173-1-npache@redhat.com Link: https://lore.kernel.org/20260717064502.1980173-2-npache@redhat.com Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size") Co-developed-by: David Hildenbrand <david@kernel.org> Signed-off-by: David Hildenbrand <david@kernel.org> Signed-off-by: Nico Pache <npache@redhat.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Barry Song <baohua@kernel.org> Cc: Byungchul Park <byungchul@sk.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
12 daysmm: memcg: initialize *locked in memcg1_oom_prepare() stubBreno Leitao
mem_cgroup_oom() passes an uninitialized "locked" to memcg1_oom_prepare() and reads it back in memcg1_oom_finish(): bool locked, ret; ... if (!memcg1_oom_prepare(memcg, &locked)) return false; ret = mem_cgroup_out_of_memory(memcg, mask, order); memcg1_oom_finish(memcg, locked); This relies on memcg1_oom_prepare() setting *locked whenever it returns true. The CONFIG_MEMCG_V1=y version does, but the stub used when CONFIG_MEMCG_V1=n returns true without touching *locked, so memcg1_oom_finish() consumes an uninitialized value. On a memcg OOM this is reported by UBSAN: UBSAN: invalid-load in mm/memcontrol.c:1932:27 load of value 0 is not a valid value for type 'bool' (aka '_Bool') Initialize *locked to false in the stub; with cgroup v1 compiled out there is no OOM lock to take. Link: https://lore.kernel.org/20260716-memcg-oom-uninit-locked-v2-1-63631d878eb4@debian.org Fixes: e93d4166b40a ("mm: memcg: put cgroup v1-specific code under a config option") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: SeongJae Park <sj@kernel.org> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
12 daysMerge tag 'for-net-2026-07-28' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_sync: Fix advertising data UAFs - hci_conn: hold conn reference fixes - L2CAP: fix UAF in l2cap_le_connect_rsp - RFCOMM: validate skb length in rfcomm_recv_frame - ISO: Locking fixes - SCO: give the socket its own sco_conn reference - MGMT: fix UAF in pair command cancellation - MGMT: fix pending command UAF in EIR updates - HIDP: reject frames without a transaction header - HIDP: validate numbered report payloads - btmtk: Fix short read errors in btmtk_usb_uhw_reg_read() - btmtk: Fix short read errors in btmtk_usb_reg_read() - btusb: Fix short read errors in btusb_qca_send_vendor_req() - btintel: Validate length before parsing diagnostics TLV * tag 'for-net-2026-07-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: (31 commits) Bluetooth: SCO: give the socket its own sco_conn reference Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req() Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read() Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read() Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync Bluetooth: hci_sync: hold conn in hci_past_sync() callback Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks Bluetooth: hci_conn: hold conn reference in abort_conn_sync() Bluetooth: btintel: Validate length before parsing diagnostics TLV Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero Bluetooth: ISO: fix refcounting of iso_conn Bluetooth: ISO: ensure no dangling hcon references in iso_conn Bluetooth: ISO: avoid deadlocks in iso_sock_timeout Bluetooth: ISO: fix leaking sk after socket release Bluetooth: ISO: hold sk properly in iso_conn_ready Bluetooth: ISO: validate sockaddr_iso first in iso_sock_rebind_bis() Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos ... ==================== Link: https://patch.msgid.link/20260728201527.2456032-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
12 daysdrm/amd/display: use proper context for loggingJiri Slaby (SUSE)
The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx Closes: https://bugzilla.suse.com/show_bug.cgi?id=1271175 Closes: https://lore.kernel.org/all/a9ee54e6-2413-4156-9bde-d528ae3c63a3@kernel.org/ Fixes: 1296423bf23c ("drm/amd/display: define DC_LOGGER for logger") Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Lakha, Bhawanpreet <Bhawanpreet.Lakha@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <siqueira@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: cap GTT size to physical RAM on APUsHarkirat Gill
On APUs, the GTT pool is backed by system RAM, but its size is not bound to the non-carveout memory that actually backs it. A user can end up with GTT + VRAM exceeding total physical memory through the following sequence: - Have a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS by increasing the UMA Frame Buffer Size (VRAM) to 64GB. - The previously set GTT value (~100GB) persists, even though the new non-carveout space (64GB) can no longer back it. This leads to a case where kernel reports GTT (100GB) + VRAM (64GB) despite the sum being greater than total physical memory (128GB). Cap the GTT size to totalram_pages() on APUs. totalram_pages() already excludes the VRAM carveout, so the resulting GTT can never exceed the system RAM that actually backs it. Signed-off-by: Harkirat Gill <harkirat.gill@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Assisted-by: Claude:claude-opus-4 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5dafdd649280c7dc6c22c8f877da3f54fcc441e1) Cc: stable@vger.kernel.org
12 daysdrm/amd/pm: use milliwatts for GPU power sensorsYang Wang
GPU average and input power backends report a mix of whole watts, milliwatts, Q24.8 watts and decimal-packed fractions. Q24.8 is inherited from the legacy PowerPlay sensor format. Milliwatts are a more natural unit for the hwmon and pm_info consumers in amdgpu_pm.c. A common decoder cannot distinguish these formats, and converting native milliwatts through Q24.8 also loses precision. Use milliwatts as the internal unit across all PPT and PowerPlay backends. Decode Q24.8 only at the legacy smu7 input boundary and encode it only for the raw amdgpu_sensors debugfs interface. This gives hwmon, pm_info and the sensor ioctl one unambiguous unit while preserving the format used by UMR. Fixes: 5b79d0482f3c ("drm/amd/pp: Remove struct pp_gpu_power") Fixes: 01992b121fb6 ("drm/amd/pm: fix amdgpu_pm_info power display units") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reported-by: Lars Nieradzik <l.nieradzik@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 757ba0790bafec47a507e9662bf380f2e027d420) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: restore UMD profile pstate after runtime resumeCandice Li
Runtime suspend runs GFX hw_fini and clears perfmon clock gating while the UMD profile DPM level remains set in software. Re-apply stable pstate after a successful runtime resume when a profile mode is active. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 138531c8850cc247aa12b104bb29ea387bcdcbb1) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: Silence link_dpms I2C retimer failuresAlan Swanson
Commit a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C") had also changed the "Set retimer failed" messages from DC_LOG_DEBUG() to DC_LOG_ERROR(). This unfortunately can create log spam. Change those back to DC_LOG_DEBUG() only. Fixes: a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5520 Signed-off-by: Alan Swanson <reiver@improbability.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit da8609eef18b0a3490d0e1fa9440659fadc8194d) Cc: stable@vger.kernel.org
12 daysdrm/amdkfd: hold event_mutex while checkpointing CRIU eventsWilliam Palacek
kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Signed-off-by: William Palacek <William.Palacek@amd.com> Reviewed-by: Alysa Liu <Alysa.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: check if dml21_add_phantom_plane() is successfulAlex Deucher
Verify that the phantom plane was allocated to avoid a later segfault. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4970 Fixes: 70839da63605 ("drm/amd/display: Add new DCN401 sources") Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: Fix divide-by-zero in calculate_mcache_setting on zero viewportGeorge Zhang
If a plane reaches calculate_mcache_setting with a zero-area viewport, calculate_mcache_setting exits early with num_mcaches == 0 and mvmpg_width/height == 0. This will cause a divide-by-zero panic and can also cause an underflow on num_mcaches. Fix this by changing calculate_mcache_setting to bool and adding guards after each calculate_mcache_row_bytes call. If num_mcaches or mvmpg_width/height is zero, return a false. Callers will propagate the failure as a rejected mode, which prevents the panic. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5302 Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 29c0f7c655f47bcbd575ff75e58480df6ec3c9da) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: Add AV mute wait frames to dce110_set_avmuteRay Wu
Port the three-frame wait logic from dcn30_set_avmute to dce110_set_avmute so that older DCN versions (1.0, 2.0) also wait for GCP packets to be sent out before proceeding. This ensures HDMI sinks properly process the mute state, preventing garbled display after link re-establishment. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5167 Reviewed-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 414da24137ace80d8c59fefd43ba3ec9f5f854ba) Cc: stable@vger.kernel.org
12 daysdrm/amd/pm: fix torn gpu metrics readsYang Wang
amdgpu_dpm_get_gpu_metrics() returns a pointer to the shared metrics cache after dropping adev->pm.mutex. The sysfs path then copies from that pointer. Another reader can refresh the cache in place during the copy and return a snapshot containing data from two generations. Pass caller-provided storage through the DPM interface and copy the metrics while the mutex is held. This keeps the cache pointer private and makes each sysfs read observe one complete sample. Fixes: 25c933b1c4fc ("drm/amd/powerplay: add new sysfs interface for retrieving gpu metrics(V2)") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 862333bb48693ecafcae25af0c9d9ec31015ac77) Cc: stable@vger.kernel.org
12 daysdrm/amd/pm: fix pptable use-after-freeYang Wang
amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. Fixes: 1684d3ba4885 ("drm/amd/amdgpu: change pptable output format from ASCII to binary") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: enable mode2 reset for SMU IP v15.0.5Kanala Ramalingeswara Reddy
Set the default reset method to mode2 for SMU 15.0.5. Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com> Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 314d49abe315cd0d0a872a43f68f08be43a305c8)
12 daysdrm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignmentWilliam Palacek
eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. Fixes: 42ea9cf2f16b ("drm/amdkfd: Relax size checking during queue buffer get") Signed-off-by: William Palacek <William.Palacek@amd.com> Reviewed-by: Alysa Liu <Alysa.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ae443117b742c357bfef3a7bddabf76fcf86e9ef) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: Fix NBIO 7.11.5 offsetsShubhankar Milind Sardeshpande
Fix NBIO 7.11.5 related offsets Signed-off-by: Shubhankar Milind Sardeshpande <Shubhankar.MilindSardeshpande@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit dcc27ae3092211c913a1bea04618c4faf1234d48)
12 daysdrm/amdgpu: Enable support for PSP 15_0_5Shubhankar Milind Sardeshpande
Add PSP 15.0.5 related offsets for GFX to KMD interface and enable support for it. Co-developed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Shubhankar Milind Sardeshpande <Shubhankar.MilindSardeshpande@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b01e244c82c5d033d7424a64abe4079f3fceb869)
12 daysdrm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLEGang Ba
Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. Signed-off-by: Gang Ba <Gang.Ba@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: move debug_vm handling to amdgpu_cs_parser_finiPierre-Eric Pelloux-Prayer
The commit referenced below restarts the CS if the validation is still in progress. When debug_vm is enabled, all BOs from the CS are invalidated so we will hit an infinite loop. To avoid that, defer BO invalidation to amdgpu_cs_parser_fini. Fixes: 59720bfd8c6d ("drm/amdgpu: restart the CS if some parts of the VM are still invalidated") Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8c990ee9daa295462df24982ce6878db997a380a) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: Update driver if header for SMU V15.0.5Kanala Ramalingeswara Reddy
Update smu v15.0.0 driver if header to be v15.0.5 compatible. Signed-off-by: Kanala Ramalingeswara Reddy <Kanala.RamalingeswaraReddy@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3ee6561f8ae0ae3c80d04429361a6e06589693fc)
12 daysdrm/amdkfd: Handle invalid event type in CRIU event restoreDavid Francis
In kfd_criu_restore_event, there was no handling for the event priv data having an invalid event type. The priv data here is untrusted and can be invalid. In that case, fail with EINVAL. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2e8e9963cd5c41aa14fd5316bf9ec92e7a0e3097) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: Update message IDs to PMFW to correctly gather GFXOFF residency logsFares Soliman
Updates PPSMC_MSGs and set/get functions for gathering GFXOFF logs on Van Gogh. Logs are now gathered live rather than starting then stopping logging and reading an average value afterwards. This is in accordance to changes made in PMFW. In regards to messageID 0x52, the old interface uses a start/stop parameter, and the new one doesn't. The firmware is checked to determine which method to use. v2: added firmware guard to new interface, old interface kept as fallback Signed-off-by: Fares Soliman <Fares.Soliman@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 482e2cadea8c34ae4e733f269a640d6b04fc9262)
12 daysdrm/amdgpu: Pack nested ucode_info structAlex Hung
Building for ARCH=um with W=1 C=1 makes the "amd_sriov_msg_vf2pf_info must be 1 KB" static assertion in amdgv_sriovmsg.h fail under sparse, exposed after UML builds were enabled. Sparse does not honor #pragma pack(push, 1) for the nested ucode_info struct, so it sizes each element as 8 bytes instead of 5 and computes the surrounding structure as larger than 1 KB. The compilers get this right via the enclosing pragma, but the annotation should be explicit. Fixes: af3f2f5db265 ("drm/amdgpu: Remove UML build exclusion from Kconfig") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607091659.SHEscT0c-lkp@intel.com/ Cc: Harry Wentland <harry.wentland@amd.com> Assisted-by: Copilot:Claude-Opus-4.8 Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1d8cfeb69daa863a70134b8ed6df8055c418a5b0)
12 daysdrm/amdgpu: Fix __rcu fence pointer accessesAlex Hung
Building for ARCH=um with W=1 C=1 makes sparse report "incompatible types in comparison expression (different address spaces)" warnings in the KFD code, exposed after UML builds were enabled: - amdgpu_amdkfd_fence.c compares the __rcu-annotated dma_fence.ops pointer directly in to_amdgpu_amdkfd_fence(). - amdgpu_amdkfd_gpuvm.c compares the __rcu eviction fence pointer directly in amdgpu_amdkfd_gpuvm_restore_process_bos(). Fixes: af3f2f5db265 ("drm/amdgpu: Remove UML build exclusion from Kconfig") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607091659.SHEscT0c-lkp@intel.com/ Cc: Harry Wentland <harry.wentland@amd.com> Assisted-by: Copilot:Claude-Opus-4.8 Signed-off-by: Alex Hung <alex.hung@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 764f241ad227bb942e5b0b8b4d9898f1a4175605)
12 daysdrm/amdkfd: fix QID bit leak in pqm_create_queue()Vladimir Marioukhine
When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 Reported-by: Deucher, Alexander <alexander.deucher@amd.com> Signed-off-by: Vladimir Marioukhine <Vladimir.Marioukhine@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f) Cc: stable@vger.kernel.org
12 daysdrm/amd/display: Increase HDMI AV mute wait from 2 to 3 framesRay Wu
Some HDMI sinks need additional GCP packets to properly process the mute state before the timing generator is disabled, especially after link re-establishment with HDMI 2.0 scrambling enabled. Waiting for only 2 frames is insufficient for certain monitor firmware, resulting in garbled display output on resume from suspend. Increase the AV mute wait in dcn30_set_avmute() from 2 to 3 frames to ensure the sink receives enough GCP packets. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5167 Assisted-by: Cursor:Claude-Opus-4.6 Reviewed-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0c0d5174b09640d8b560764aa5a177630e076e93) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu: skip clearing empty freed VM list on GEM closeBob Zhou
amdgpu_vm_clear_freed() allocates an amdgpu_sync object and walks the VM reservation fences via amdgpu_sync_resv() before checking whether vm->freed has anything to clear. Return early when the list is empty to skip this overhead on a hot path (every GEM close and command submission). Signed-off-by: Bob Zhou <bobzhou2@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8ba869e852d4f1b1c0e5ae9225c77f7ceccbe056)
12 daysdrm/amdgpu: dont pin wptr bo instead use eviction fenceSunil Khatri
Instead of pinning the wptr bo attach the eviction fence to the bo to make sure it remains valid all the time. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7264bc10c7c657a54603c7fc058bf8e15f18ce12)
12 daysdrm/amdkfd: Add bounds check for CRAT subtype lengthWilliam Palacek
The CRAT parser validates that the subtype header fits within the image, but does not verify that the advertised subtype length fits. A malformed CRAT table with an oversized length field causes out-of-bounds reads when kfd_parse_subtype() casts the header to specific subtype structures. Add validation that sub_type_hdr + length does not exceed the image boundary before parsing the subtype contents. Signed-off-by: William Palacek <William.Palacek@amd.com> Reviewed-by: Alysa Liu <Alysa.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d) Cc: stable@vger.kernel.org
12 daysdrm/amdgpu : update mmhub eco sec lvl for vcn5_3Suresh Guttula
This patch requests PSP to set the sec lvl for vcn and jpeg. Signed-off-by: Suresh Guttula <suresh.guttula@amd.com> Reviewed-by: McRae Geoffrey<Geoffrey.McRae@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4c8b8472f85a730a6853ab68474f210143f42b5a)
12 daysx86/boot: Add volatile, clobbers and zero-length test in memcmp()Mauricio Faria de Oliveira
Add the volatile qualifier and clobbers parameter to prevent bugs with instruction reordering and optimization. Also add TEST for the zero-length case to set ZF, as, if the count register is zero, the REPE prefix does not run the CMPSB instruction, leaving the ZF flag undetermined. [ bp: Add a comment about the len==0 case. ] Fixes: 62bd0337d0c4 ("Top header file for new x86 setup code") Closes: https://sashiko.dev/#/patchset/20260701-pvh-kasan-inline-v6-0-ba99045dfa9f%40igalia.com Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/all/20260721-pvh-kasan-inline-v7-2-38979a50cef0@igalia.com
12 daysdrm/amd/display: use proper context for loggingJiri Slaby (SUSE)
The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx Closes: https://bugzilla.suse.com/show_bug.cgi?id=1271175 Closes: https://lore.kernel.org/all/a9ee54e6-2413-4156-9bde-d528ae3c63a3@kernel.org/ Fixes: 1296423bf23c ("drm/amd/display: define DC_LOGGER for logger") Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Lakha, Bhawanpreet <Bhawanpreet.Lakha@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <siqueira@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdkfd: Evict SVM BOs synchronously from TTM evictionPhilip Yang
svm_range_evict_svm_bo_worker() migrated an SVM BO's pages back to system memory from a work item that took mmap_read_lock. When an mmap writer was pending, that read lock blocked behind the writer while the thread allocating a new migration VRAM BO waited on this BO's eviction fence - a circular wait that hung the SVM workers. Evict the SVM BO synchronously from the TTM eviction path (amdgpu_ttm_bo_eviction_valuable) instead of deferring to a work item. The BO is already reserved and the lock order is mmap_lock -> BO reservation, so only trylock the owning process's mmap lock; on contention return -EBUSY so TTM skips this BO. This removes the eviction work item and the enable_signaling path, so no worker can block on mmap_read_lock. The SVM BO uses AMDGPU_GEM_CREATE_DISCARDABLE, so ttm_bo_evict takes the pipeline_gutting path and skips allocating a system memory placement. That would be wasted work, since svm_migrate_vram_to_ram allocates the system pages and copies the data back itself. Eviction now migrates ranges directly, so it must serialize with the owning process: it trylocks migrate_mutex under svm_bo->list_lock before unlinking the range, and svm_range_free() unlinks the range then waits on migrate_mutex, so a concurrent eviction cannot free a range under it. Drop the mm reference with mmput_async so exit_mmap() does not run under the BO reservation. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdkfd: Fix signal reset eventAmber Lin
When a mode reset happens, driver needs to notify the process on that GPU a reset event is happening. The existing code assumes the process is using the GPU that is getting mode reset, which is not always true. For example, on a 8G system, the process may be only using GPU 0~4 but a mode 2 reset is resetting the all 8 GPUs connected by XGMI. Trying to find a process on GPU 5~7 will fail, which is fine and should skip the event signal. Signed-off-by: Amber Lin <amber.lin@amd.com> Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu: cap GTT size to physical RAM on APUsHarkirat Gill
On APUs, the GTT pool is backed by system RAM, but its size is not bound to the non-carveout memory that actually backs it. A user can end up with GTT + VRAM exceeding total physical memory through the following sequence: - Have a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS by increasing the UMA Frame Buffer Size (VRAM) to 64GB. - The previously set GTT value (~100GB) persists, even though the new non-carveout space (64GB) can no longer back it. This leads to a case where kernel reports GTT (100GB) + VRAM (64GB) despite the sum being greater than total physical memory (128GB). Cap the GTT size to totalram_pages() on APUs. totalram_pages() already excludes the VRAM carveout, so the resulting GTT can never exceed the system RAM that actually backs it. Signed-off-by: Harkirat Gill <harkirat.gill@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Assisted-by: Claude:claude-opus-4 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amd/pm: use milliwatts for GPU power sensorsYang Wang
GPU average and input power backends report a mix of whole watts, milliwatts, Q24.8 watts and decimal-packed fractions. Q24.8 is inherited from the legacy PowerPlay sensor format. Milliwatts are a more natural unit for the hwmon and pm_info consumers in amdgpu_pm.c. A common decoder cannot distinguish these formats, and converting native milliwatts through Q24.8 also loses precision. Use milliwatts as the internal unit across all PPT and PowerPlay backends. Decode Q24.8 only at the legacy smu7 input boundary and encode it only for the raw amdgpu_sensors debugfs interface. This gives hwmon, pm_info and the sensor ioctl one unambiguous unit while preserving the format used by UMR. Fixes: 5b79d0482f3c ("drm/amd/pp: Remove struct pp_gpu_power") Fixes: 01992b121fb6 ("drm/amd/pm: fix amdgpu_pm_info power display units") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reported-by: Lars Nieradzik <l.nieradzik@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu: restore UMD profile pstate after runtime resumeCandice Li
Runtime suspend runs GFX hw_fini and clears perfmon clock gating while the UMD profile DPM level remains set in software. Re-apply stable pstate after a successful runtime resume when a profile mode is active. Signed-off-by: Candice Li <candice.li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amd/display: Fix DML file discovery for out-of-tree buildsPrike Liang
By anchoring the search to the DML top-level Makefile directory, FPU CFLAGS are now correctly applied to all relevant source files. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu/ttm: Use more optimal copy packet sizes for copy and fillTimur Kristóf
Currently when amdgpu copies or fills a buffer, it uses the maximum byte count supported by the copy engine (SDMA). This is problematic when the maximum byte count is not aligned to 256 bytes because it then can't use all memory channels optimally and can cause the SDMA to operate in its slower byte mode (as opposed to the faster dword mode). For example, when copying a 10 MiB buffer on SDMA v2.4, we get 5 packets copying 2097151 bytes and 1 packet copying the remaining 5 bytes. All 6 packets are misaligned and operate in byte mode. For this example, the optimal solution would be to have 5 packets each copying 2096896 bytes and 1 last packet to copy the remaining 1280 bytes, in which case all 6 packets are aligned to 256 bytes and operate in dword mode. Let's use the following scheme from now on: When byte count is dword-aligned and fits a single packet, just emit a single packet. Otherwise, align the copy packet size down to 256 bytes for optimal use of memory channels and to ensure the HW can use the dword mode. This assumes that the starting addresses of BOs are always dword aligned, which should be the case for every copy operation in the kernel, because the kernel always copies pages. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu: Consistently define pci_device_ids using named initializersUwe Kleine-König (The Capable Hub)
... and PCI device helpers. The struct pci_device_id array of supported device was initialized by list expressions. This isn't easily readable if you're not into PCI. Use PCI_DEVICE* helper macros and named initializers which is more explicit and thus easier to parse. Also skip explicit assignments of 0 (which the compiler then takes care of). The secret plan is to make struct pci_device_id::driver_data an anonymous union (similar to https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/) and that requires named initializers. But it's also a nice cleanup on its own. This change doesn't introduce changes to the compiled pci_device_id array. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdkfd: allow CWSR grace period of 0 on supported firmwareWilliam Palacek
The debugger sets the CWSR grace period via AMDKFD_IOC_DBG_TRAP and may request a value of 0. An earlier change clamped 0 to 1 unconditionally because most firmware revisions locked up when given an infinite (0) grace period. Firmware has since been fixed on most ASICs, so gate the clamp on ASIC type and MEC firmware version and allow 0 where the running firmware is known to handle it. Navi3x and MI350 support 0 in every firmware revision and need no version check. MI100 never received the firmware fix and is kept clamped. Any unlisted or future ASIC defaults to the safe (clamped) behaviour. Signed-off-by: William Palacek <William.Palacek@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu: reset VI ASIC on MacBookPro15,1Andre Eikmeyer
After S3, reloading amdgpu on MacBookPro15,1 systems with a Radeon Pro 555X or 560X fails while loading the SMU firmware. The existing SMC register check does not request a reset because the registers do not reliably reflect the stale SMU state on these machines. Frederick Morlock found that forcing a VI ASIC reset allows the driver to initialize again. This patch limits his workaround to the exact PCI device, Apple subsystem device and revision combinations used by these two GPUs, leaving other VI hardware unchanged. Suggested-by: Frederick Morlock <me@freddy.us> Signed-off-by: Andre Eikmeyer <dev@deq.rocks> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amd/display: Silence link_dpms I2C retimer failuresAlan Swanson
Commit a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C") had also changed the "Set retimer failed" messages from DC_LOG_DEBUG() to DC_LOG_ERROR(). This unfortunately can create log spam. Change those back to DC_LOG_DEBUG() only. Fixes: a4f01bf729b2 ("drm/amd/display: Refactor and fix link_dpms I2C") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5520 Signed-off-by: Alan Swanson <reiver@improbability.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amd/display: Don't use tiling flags anymoreTimur Kristóf
All supported GPU generations now support DRM format modifiers. Remove all code from amdgpu_dm that dealt with tiling flags. Note that the legacy non-DC display code still relies on tiling flags, so we can't remove them outside of DC until we also remove the legacy display code. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Link Mauve <linkmauve@linkmauve.fr> Tested-by: Nikola Medić <nmedic89@gmail.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amd/display: Support DRM format modifiers on GFX6-8Timur Kristóf
Expose displayable DRM format modifiers based on which tiling modes are supported by the GFX block. Technically, DCE (Display Controller Engine) could support all possible permutations of all parameters independently of what GFX supports, with the limitation that it can only display LINEAR images and the displayable micro tiling mode (MICROTILE == DISPLAY). It doesn't make sense to expose all possible permutations of macro tiling modes, so let's just expose what the GFX block of the current chip supports. The following modes will be advertised: - 2D_TILED_THIN1 + DISPLAY + macrotile params [1] - 1D_TILED_THIN1 + DISPLAY - LINEAR [1] The macro tiling parameters depend on how many bits per pixel of the specific surface has and how the chip is configured. There is only one set of valid macrotile params for a given surface. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Link Mauve <linkmauve@linkmauve.fr> Tested-by: Nikola Medić <nmedic89@gmail.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu: Convert tiling flags to modifiers on GFX6-8Timur Kristóf
This is done for consistency between different GPU generations. Tiling flags are "implicit modifiers" which are used on AMD GPUs to let the kernel know the tiling information without modifiers. Convert the tiling flags to modifers on GFX8 and older, so that the DC display driver can rely on them like on newer generations. Note that this code path will only be taken when DC actually exposes any modifiers on GFX6-8, which is handled in a subsequent commit after this one. This code path mainly exists for legacy compositors which don't support explicit DRM format modifiers and rely on the tiling flags, and for compatibility with old Mesa that didn't support modifiers on GFX6-8. Add amdgpu_display_verify_sizes_gfx6() to validate modifiers on GFX6-8 and only accept the modes that the display driver really supports, as well as validate the FB sizes. Additionally adjust check_tiling_flags_gfx6() to allow the LINEAR_GENERAL mode and disallow the ROTATED mode which has never been supported by Mesa or Linux and was mistakenly allowed previously. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Link Mauve <linkmauve@linkmauve.fr> Tested-by: Nikola Medić <nmedic89@gmail.com> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> Reviewed-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/fourcc: Add modifiers for AMD GFX6-8Timur Kristóf
GFX6-8 are the oldest GPUs supported by the amdgpu kernel driver, and the last ones that didn't support DRM format modifiers until now. These are the Southern Islands, Sea Islands and Volcanic Islands families of GPUs. On GFX6-8, the GFX block can only use pre-determined tiling modes which are programmed by the kernel according to the tiling mode table. GFX6 uses the GB_TILE_MODE0...31 registers, and GFX7-8 also has GB_MACROTILE_MODE0...15 registers. DCC is also supported on GFX8, albeit not displayable. Note that the tiling table is uAPI and userspace relies on specific modes being present at specific indices. How the tiling works is primarily determined by the so-called array mode. Use the TILE field to specify the array mode. Pixel data is organized into micro tiles. Each micro tile may be 8x8 / 8x8x4 / 8x8x8 pixels, depending on the array mode. Add the MICROTILE field to specify microtile mode. Microtiles may be further organized into macro tiles, which have many configurable parameters. Macro tile mode selection depends on how many bits per pixel an image has. Add the PIPE_CONFIG, TILE_SPLIT, BANK_WIDTH, BANK_HEIGHT, MACRO_TILE_ASPECT, NUM_BANKS fields to specify parameters of macro tiled modes. Furthermore, tiling is also influenced by memory configuration. Old RFC patches received feedback concerning that, so I looked into it specifically: GB_ADDR_CONFIG.ROW_SIZE needs to be considered when calculating TILE_SPLIT, but does not need to be included in the modifiers, and also PIPE_INTERLEAVE matters, but it's hardcoded to the same value on all GFX6-8 GPUs and changing it would break userspace, so let's assume it isn't going to change. Therefore we don't need to include that in modifiers. Mesa also reads NUM_RANKS but actually doesn't use its value on GFX6-8. As a side note, tiling works similarly on GFX4-5 (that is Evergreen and Northern Islands). But that will need some additional PIPE_CONFIG enum values as well as some extra fields not relevant to GFX6-8. Initially, let's only expose the tiling modes that are most relevant to sharing buffers between different processes: Exposed array modes (TILE field): - 1D_TILED_THIN1: micro tiled only - 2D_TILED_THIN1: macro tiled Exposed micro tile modes (MICROTILE field): - DISPLAY: supported by DCE (the display engine) - THIN: more efficient but not displayable Exposed macro tile modes: All possible parameters (25088 permutations). More modes may be exposed in the future as needed. Technically, the amount of possible combinations of all possible tiling parameters is in the range of hundreds of thousands, but in practice, there are just a handful of possible modifiers for a surface. For example on GFX8, a surface would have these modifiers, from best to worst performance: - 2D_TILED_THIN1 + THIN + DCC + macrotile params [1] - 2D_TILED_THIN1 + THIN + macrotile params [1] - 2D_TILED_THIN1 + DISPLAY + macrotile params [1] - 1D_TILED_THIN1 + THIN - 1D_TILED_THIN1 + DISPLAY - LINEAR [1] The macro tiling parameters depend on how many bits per pixel of the specific surface has and how the chip is configured. There is only one set of valid macrotile params for a given surface. DCC is only supported by GFX8 and newer, and only with non-displayable macrotiling modes. When sharing buffers between different GFX6-8 GPUs, it is very unlikely that they support the exact same macrotiling configuration, so they will likely need to use micro tiled modes, which are still much better than using linear buffers. (Note that currently Mesa always uses LINEAR when copying between two GPUs.) Suggested-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Marek Olšák <maraeo@gmail.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu/gfx12.1: drop all BUG()sAlex Deucher
There's no need to crash the kernel for these cases. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
12 daysdrm/amdgpu/gfx12: drop all BUG()sAlex Deucher
There's no need to crash the kernel for these cases. Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-09 13:26:55 +0000